How Often do you Commit?
Received an email today where I thought I would post my answer:
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
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
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.