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.