How Often do you Commit?

Received an email today where I thought I would post my answer:

Hey Howard,

I have just started using git and github, and I wanted to ask a couple of best practices questions. How frequently is it good to make commits? Small changes or only big changes? How detailed should messages be? I have just been using git at the command line and committing with git commit -m “…”.

Any advice is appreciated. This seems like one of those amorphous areas where googling would get a wide range of opinions.

That is a very good question, and while I have an opinion, so does everyone else. Obviously, you’ll form your own idea was is “best practice” as you keep using source code control systems.

Clearly, for your own projects, you can commit anytime, but one of the advantages of committing frequently is sharing code…either to your team mates, or (even with your personal projects) between computer systems. For instance, my dot-files project contains the code for my shell and editor initialization, and since these are the same between my work, home and server computers, I tend to commit with every change that actually works.

I think most people and projects commit for every new feature or bug fix. My projects at work trigger a version with every commit to master, so this means that each version has exactly one change. Easier to identify the culprit when version 3.1.4 broke the system, but version 3.1.3 was fine.

What if a feature is big and requires a team of engineers? Not a problem. Create a feature branch that can be shared between the engineers, and when the feature is complete, you have a single merge down to master.

On your own personal repository, you can achieve a similar thing by smooshing multiple commits on master into a single commit that represents a single feature. Since branches are so easy to make with Git, most engineers just go with the feature branch, but to keep your Git commit history nice and clean, sometimes you do need to dabble in the dark arts and squash commits.

I’ve been tempted to teach my editor to automatically commit all work before the computer goes to sleep, but if I did that, I would often then want to squash multiple commits into a single one.

The bestest practice is when you can have Git work with a review system like Gerrit. In the Gerrit Workflow, your Git commit doesn’t go to master, but goes on a review branch for your colleagues to review. You would then repeatedly patch that review until everyone was happy, and then you submit the results to master. You get the benefits of sharing code with team mates, as a clean Git history.