Commit Early - Commit Often

Small changesets are good, large changesets are evil. It's (nearly) as simple as that.

Save early, save often is a well known rule amongst computer gamers, especially for role playing games. Now, role playing games and software development have a few things in common which allows a transfer of that rule.

Here's what ↗Robin Luckey, one of the developers of ↗Ohloh, says about this: Infrequent, large changes can be a sign of trouble - it can, in some cases, indicate destabilizing changes to the code.

Robin Luckey knows his context and thus has wisely chosen the correct, a very soft wording. He writes can be. The context of the wording is open source software development. There, people develop software in their spare time. And most open source developers are involved in more than just one project. A developer performs changes to project A in one week, and then to project B in the next week. Also, there is real life, and during holidays there's usually more activity going on. A good, continuous style of development performed by a single developer may look like infrequent large changes. What Robin said is correct. The reader just has to have the context on her mind.

Under the hood, there are two things to look at. One is that development may look like burps. The other is the size of changesets. For now I want to focus on the changesets.

When development looks like burps

When comparing commercial software development to open source development, things look a bit different. In commercial development, a developer usually works on a project over longer period of time. He spends a constant amount of effort on it each day. If that is the case, I would rewrite Robin's statement as: Infrequent, large changes most likely are a sign of trouble - it will, in many cases, indicate destabilizing changes to the code. And even more: Infrequent, large changes most likely are a sign of trouble - it will, in many cases, indicate destabilizing changes to the code and a sub-optimal development environment.

Why do I think like this?

There are several reasons why I think like this. In this blog entry, I want to focus on one certain aspect, the commit policy - or checkin or deliver policy, depending on which VCS is used. Or let's rather call it culture, not policy, because usually this is something informally performed by developers.

Independently of whether you have a stream, a branch or just a local copy (sandbox, snapshot view or whatever) - what you have is a branch. And if you do not actively do something against divergence, your branch will diverge from its origin (trunk, HEAD, MAIN/Latest, the integration stream or whatever it is called). But usually you want to bring it back some day. Some day your branch and its origin shall reunite again. You want to merge, deliver, reintegrate.

There are two things which cause divergence:

Your own changes made to your branch

This is your development and it will cause your branch to diverge from its origin.

Changes made to the origin

Time does not stand still. The origin of your branch will become changed by development, too.

This is like a pair of scissors, which is opening. One blade is moved open by changes to your branch. The other blade is moved open by changes to the origin.

The wider the pair of scissors is open, the more troublesome the required merge will be in the end.

Updating your working copy to the latest version of your origin on a regular basis will keep the distance to your origin at a minimum. It will move the origin blade back to its original position. Whatever version control system you use, update, merge, rebase often.

Delivering stable changes back as often as possible is moving your branch blade back to its original position.

Therefore: Commit early, commit often.

About

About Cher

Cher is a computer hacker that actively contributes to open source software and also runs some of his own projects as open source.

Cher's homepage is ↗http://www.riedquat.de/.