Article summary
Git is the quintessential version control tool, and using it is an essential skill for most software developers. I’ve found that Git is not often taught in university computer science courses, or, when it is, it often lacks practical applications. This leads to new developers learning Git as a part of the firehose of new information when joining the industry. In turn, that can lead to forming bad habits and misunderstanding the basics. In this post, I want to discuss and correct several common mistakes and bad habits I see new developers make. And no I won’t harp on commit messages starting with an imperative present tense verb.
Git Add
The Bad Habit: git add . all the things!
One of the very first Git commands that every tutorial will cover is git add. Tutorials will often express this as adding files to the index from the working tree or in terms of staging changes for a commit. The lesson typically covers one of git add --all, git add -A, or git add . and then leaves it at that.
These commands are great and are probably what you want to use in most cases, but understanding that you can add individual files to the index is vital in some cases. Leaning too heavily on git add -A or git add --all means that anytime you want to stage files for a commit, you have to go clean up all of your debugging code–how tedious! I also see many new developers not realizing that the period in git add . refers to a directory, specifically the current directory. Recognizing that the period is fulfilling a path parameter, you can start to add more granularly by specifying paths to specific files or groups of files.
Git Commit
The Bad Habit: git commit -m “some stuff”, git commit -m “WIP”, git commit -m “it works”, …
I promised I wouldn’t bring up the obnoxious “imperative present tense verb commit messages” rule, but that doesn’t mean I can’t emphasize helpful commit messages. The power of a helpful commit message is two-fold. First, when you’re writing a detailed commit message, it helps you to reflect on what this commit changes in the code. It’s a quick summary to keep things fresh in your head and ensure you’re making small meaningful changes. Second, the developers that come after you will appreciate it (even if that is yourself six months in the future). A great commit message can help these future developers understand the intention of the change without pouring through documentation or old backlog tickets.
I won’t pretend I don’t slip in a “WIP” commit now and then. It’s not the end of the world. But you should know that you can use git commit --amend to add in new staged changes and rename the commit. Or, if you have several successive “WIP” commits, you could use a rebase to squash them together with a more helpful message. This way you can save in-progress work with a WIP commit and then edit it later on!
Git Push
The Bad Habit: commit, push, commit, push, commit, push…
Another command that Git tutorials tend to gloss over is git push. I see many young developers get into the habit of instinctually pushing after every commit because that’s what the tutorials do. Pushing frequently is a great practice to stay in sync with your team; it’s better than pushing too infrequently. That being said, there are times when it’s unnecessary or even unwise.
The best time to push is when you have something to share with the team or when you’re stepping away from the branch for a while. If you’re pairing with another developer and you don’t intend to change who is driving, then you can keep your commits locally and push a batch of them when the time is right. If you have automatic CI pipelines, the CI build and servers will appreciate the lightened workload. The other benefit of pushing only when necessary goes back to the amending Git history stuff that I discussed earlier. Once you’ve pushed a commit, it can be a hassle to change anything about it or even undo it. If you keep your commits local, those tasks are trivial and you won’t risk making a mess on the remote.
Branches
The Bad Habit: “Oops was I on main for that?”
A challenging part of Git when starting with the CLI is remembering what branch you’re working on and how that branch relates to other branches like dev or main. Git offers two easy commands for keeping track of your current branch; either git status or git branch will let you know where you’re at. I like to be in the habit of regularly checking my working copy changed files anyway with git status, so it’s helpful that the branch is listed there too. I have also configured my command prompt to display my current Git branch for a reminder before every command. Configuring this will depend on your shell, but using Oh-My-Zsh and Spaceship Prompt I was able to come up with a prompt that is perfect for me.
Keeping track of how your current branch relates to base branches is trickier. The best way to manage this is by keeping your Git branching strategy simple. Feature branches should come straight off of the head of dev unless there’s a good reason not to. When things get a little more complicated, configuring a prettified Git log alias can be helpful. I have found Oh My Zsh’s glog alias provides everything I want in a concise package.
None of the habits I’ve described here will be disastrous to your version control or source code. But, by breaking bad habits, you can work smarter and more efficiently. I hope these points have provided some context and better practices for those just getting started learning Git.