Bigger is not always better!

Even years after switching from centralized version control to a decentralized one (or to be more precise: from Subversion to Mercurial) I still find myself stuffing different unrelated changes into one commit. Sometimes there are just some small changes to make the code compile in your current environment, sometimes you correct typos in the comments or string resources, sometimes it is just a better formatting of the code. All of these changes have nothing to do with the current bug to fix or the current feature to implement, but they end up being part of the commit – and that is just plain wrong! When it comes to commits, make them as small as possible!

Bigger is Not Always Better

A changeset is no suitcase to be packed with clothes for all types of occasions. It should have been created for one purpose only in the first place. While it is totally OK to have multiple changesets for one bugfix or feature request or refactoring, it is just bad practice to have one changeset targeting more than one of those.

Let’s say you are fixing a bug in the release branch and then want to merge it into the develop branch. There is a much lesser chance to encounter any merge conflicts when the changeset only touches the code necessary to fix the bug. Keeping the changeset small can make the difference between an automatic merge and the need for manually resolving conflicts.

If you are working in an environment that allows to connect the changesets to the corresponding bug or feature in your issue tracker, you can query for those changesets to get an estimate for a similar bug or feature. Some months later it may be quite difficult to separate the unrelated changes from the relevant ones just by analyzing the changeset – even if it is yourself doing that analysis.

There are different ways to help you keeping your commits clean. The obvious one is just skipping files that don’t belong to the change in question. If the change was not done intentionally (be it by yourself or automatically by the IDE), either revert it immediately or keep the change and uncheck the file for the commit. Sometimes the latter may be necessary just to satisfy the IDE.

The next step is to get into the files content and select only those changes that are necessary. Mercurial and Git (and probably others, too) make this a simple click on a checkbox.

As a nice side effect you get short commit comments usually fitting in one line, which makes them fully visible in the history.

I am constantly getting better in this. What about you?

Author: Uwe Raabe

Addicted to Pascal/Delphi since the late 70's