Git: is My Commit too Small?

Read more if you use version control for software development…

Don’t Break the Build

It’s easy to do. I’ve done it (lots of times) but my intention is that all tests pass with each commit. For bonus points (and who doesn’t want bonus points?), any new tests that need to be written should also be included in the commit. The commit is a little, happy parcel of code.

If you find yourself writing a series of commit messages like this then I suggest you are committing too often:

• Update widget method to cope with pears as well as apples.
• Fix up call to widget to specify apples.
• Fix test for widget method.
• Add test for pears.

That should be:

• Update widget method to cope with pears as well as apples.

If, like me, you aren’t perfect then you might find yourself committing part of the code before you realise the full extent and consequences of the change. In that case, amending the previous commit is your friend. If you don’t know how to amend a commit then that’s something you should find out. A client like Github Desktop will help you out (although knowing how to do it on the command line is useful).

Of course, never amend a commit you have shared with other developers. Which means you should be reviewing your commits before pushing them. Amending a commit is rewriting history and you’re going to cause conflict and grief if you do that.

But as Small as Possible

Small commits are easier to understand and committing often gives you a comforting set of stepping stones on your journey. I’m not suggesting you commit a complete new feature in one commit. For instance, say you want to add a new pear field to the widget: you can do that in steps:

• Add pear column to widgets table (including validation and tests)
• Update UI to allow user to change pear status of widget
• Add pear to monthly widget report

Happy Committing!