The art of the commit (in version management)

Most developers (and certainly professional shops) working with software- or webdevelopment has understood the ideas behind sourcecode version management - no matter if they choose to use cvs, subversion, git or any of the other fine systems available. How developers use these systems, can provide an easy insight into who is the dummy, the average and the great developer.

When to commit

One of the first distinguishing signs is what they commit - is the version management system used as a backup tool or as a version tracking tool. Some seem to think, you should end the day by committing all your sourcecode (no matter which state it’s in). This is really bad sign. Others commit whenever a new file is finished and thought ready to use - which is slightly better. Others again commit once - just before a new release - and has the commit contain each and every change since last release.

In my world a commit should contain a complete new feature across all the files changed to make the new feature. The commit should preferably only address one change (a new functionality or a changed feature).

The commit message

Another way to spot bad habits is in the commit message. Is there a commit message at all? - if not, it’s a bad sign. Almost as bad are meaningless comments, which may come in all sort of varieties - “work in progress”, “bugfix”, “update”, “foobar”. I’m sure they make sense to the developer at the time of committing them, but hardly 6 months later, when browsing the logs and wondering why a certain change was made.

A less common bad commit habit is the “book style” - where the comment either contain a delta of the changed lines (literally or as a description) or the length of the comment is a small story explaining the reason for the change, why it was made the way it was and on and on.

I’d any day prefer seeing a reference to a bug/ feature tracking system (bugzilla, trac or anything like it), and a brief summary of the change in a 140 characters a less.