5 Reasons for Keeping Your Git Commits as Small as You Can

Keeping your commits small brings you several benefits when using Git as source code management tool and is generally good advice:

You should try to split your changes into small logical steps, and commit each of them.They should be consistent, working independently of any later commits, pass the test suite, etc.

So what exactly do you gain from following this advice?

Makes your commit messages more accurate

Writing commit messages that describe the content of your patch can be difficult. Especially when you cram many changes into a single commit. Try to follow the ‘One Single Change Per Commit’ rule and prefer two commits like

Fix logging bug in Logger.warn()

Organize imports.

over a one long commit like

Fix logging bug in Logger.warn() and organize imports.

It is not always this easy but often possible, just try it.

Makes continuous integration easier

The whole idea behind continuous integration (or CI) is to integrate your own code with the main repository as often as you can. If you make small changes and put them into single commits you may integrate them often (and probably should). Doing so minimizes merge conflicts with your team members. You can read more about CI in a Git context in Martin Fowler’s excellent FeatureBranch article.

Makes git-revert more useful

git-revert allows you to apply a single commit negatively and thereby roll it back and make it undone. This comes in handy on several occassions: When taking back a change which was inadvertently pushed too early or when taking out code once again which turns out to contain bugs. When keeping your commits small chances are you just can revert this single commit as a whole. No need for cherry picking single lines of code.

Makes git-bisect more useful (my favorite)

git-bisect is a fine bug hunting tool whenever you encounter strange behaviour which you know was not there before in an older version of your code. It deserves an article on its own.

But the basic idea is to switch back to any older version of your code which did not contain the bug, tag this version as good and then let git-bisect do its magic (it’s basically just a binary search through your commit history, which is kind of magic anyway). When git-bisect finishes its search it outputs the single commit which introduced the bug.

And that is why it’s especially useful to keep your commits small when you want to git-bisect often: When git-bisect tells you the buggy commit and it is small enough you can often enough spot the buggy line(s) immediately.

You can combine multiple commits into one large commit after all

If for some reason you believe you created too many commits when a single should have been sufficient then you can squash several commits into one with git rebase. git ready explains how squashing commits with rebase works. Beware that this only works as long as you have not already shared your local changes with anyone else.

apples soon to be tarted… image published by jek in the box {is traveling}
under a Creative Commons License.


Maximilian Hainlein

I’m working for crealytics as Social Media and Marketing Manager since 2011. My motto: “It’s better to be the needle than the haystack.”

  • Thank you for this post. It’s good to see that someone cares about commit size. I will point my teammates to it.

    May I add a 6th reason which is closely related to CI? When something goes wrong, finding the bug is much easier when you have fewer files and lines to check.

  • Matthias Lüdtke

    Anna, glad you like my post.

    Your 6th reason is a good one. I have often seen colleagues struggle when trying to integrate their large commits into mainline. When they are finally done merging it’s occasionally the case that they introduced a bug or two along the way, to boot.

  • Tomeu Vizoso

    And #7: Makes it easier to backport changes with git cherry-pick

  • May I suggest #8 – to make code archaeology easier. It’s much easier to see why someone was making a change in a small commit because there’s less code to read (as well as #1). This is especially important when someone wants to make a very similar change – the commit gives them some clues to which files are involved.

  • BTW is anyone aware of a git project that suffered bad performance by having too many commits? I am not aware of any such project and unless I become aware of a particular performance issue, I’ll continue to favour small commits and avoid squashing (which ruins the archaeologist’s day).

  • I would like to add my favorite reason: documentation.

    Whenever you want to follow some development (maybe to imitate it?), it is really, really nice if the commits are small and concise. Well, really, it is more important that each commit is a self-contained change. But that usually comes automatically when the commits are kept small.

    My favorite example for a too-large commit is when somebody combines a logical change (such as an off-by-one fix) with a variable name change. It is very hard to follow such developments if they are thrown into the same commit.

  • Dale King

    Kind of related to Glyn’s #8 but it makes using git annotate a lot more helpful as you can see more precisely why a particular line changed