4 Real-World Things I Didn’t Learn About Git in Bootcamp
I learned about Git and GitHub in the first week of bootcamp. Our curriculum had three commands: git add -A, git commit -m <commit message>, git push origin <branch>. This was enough to document my code through the program, but this isn’t how developers work with Git in the real world. Over the last six months, I’ve learned how to improve my own GitHub workflow for the sake of myself and everyone on my team.
1. Stage Specific Files
Through my second month working as an engineer, I still staged my files with git add -A , and I thought everyone else did too. It wasn’t until someone noticed unnecessary files in my pull request that I was told otherwise.
There are a few reasons one might not want to commit all of the changed files. I often add a console.log or remove something minor for testing purposes. It would be counterproductive to have git track these changes since they are not real changes to the code.
Another reason one might not want their files tracked by git is because of autogenerated files. In my last position, we used node 14.15.5. All other versions caused instability in the dev environment. If someone accidentally generated their node_modules and Pods with node 15.10.1 and merged those files into main, the project would have the wrong files. Therefore, it is better not to include autogenerated files in git unless you made deliberate changes that pertain to your work.
To stage files in VS Code, go to the version control tab and press the plus button next to the files you want to include.
2. Staying Up to Date with the Main Branch is Critical (for everyone else’s code)
When my coworker and I were discussing the merits of pulling in a git branch before merging, she said that her code always works better when she doesn’t pull in main before merging. Precisely, I thought.
When one don’t pull in main, the changes in that branch can write over some of the changes that are already in the main branch. For example, if someone changes the color of an element (and merges it into main), and I change the functionality of that element on the same line without merging in main, it could write over the new color.
3. Commenting-Out Code is Unnecessary with Version Control
In Clean Code by Robert C. Martin says that, “Few practices are as odious as commenting-out code… [because] others who see that commented-out code won’t have the courage to delete it. They’ll think it’s there for a reason…”
I’ve commented out my fair share of code and left it there. I’ve also stared at code others commented-out wondering if it’s safe to delete. Commented-out code is visual clutter that makes the codebase more difficult to work with. As Martin says in the book, this is an old-school method, and we have tools (i.e. git) to help us reference old work without it.
While I’m working on a feature, instead of commenting out old code, I like to make draft pull requests so I can reference the difference. I also try to make specific commit messages to help me find specific things in the future. If I can’t find old code with the commit message, I use git grep to search the codebase.
4. Contributions Aren’t Always Instant or Permanent
When I first graduated from bootcamp, I worked off the main branch in my personal repos because I saw the increase on my GitHub contributions graph immediately. It wasn’t until I started working that I realized that commits from other branches would show up on the graph once the pull request is merged. In fact, you get a contribution for making a PR, so good branching practices actually net more contributions.
When contributing to an organization’s repo, keep in mind that you either need to be a member of the organization or have the repo starred to keep the contributions on your graph, so it is best to star every repo you contribute to. If you leave an organization without starring the repo, your contributions will be lost forever.
Git was one of the steepest learning curves for me when I started because I didn’t understand what I was tracking. Working professionally with Git forced me to think more about the why of version control, and improving my Git workflow has helped me become a more efficient developer.
