I’m sorry but sometimes I really don’t get why even seasoned developers doesn’t learn the art of the commit message in version control system. All too often I’ve come across check-ins where the entire commit message just reads “bugfix”, “change”, “oops” or something just as mindless.
The effort of writing a useful message compared to the potential benefit seems to be one the best ratios – but of course the pay-back is usually some time away – too bad. Once you work on the same code for years – or even better inherit code from others, you’ll quickly learn to appreciate anyone who used more than 10 seconds on composing a thoughtful message for the future.
Here are 3 rules you should always, always obey when committing to a version control system.
Always leave a reference to the issue/bug tracking system.
All professional development uses some sort of issue tracking system, to keep track of bugs, new features and other changes to the system. The issue tracking system should always be able to tell who asked for a change, why it was asked for and what considerations was made before the code change. By leaving a reference to the issue tracker, it’s often much easier to get “the big picture” if the change need to be changed years later. To make sure you get it in, just write “Bug #number#: “ as the initial part of the commit message.
Don’t write what, write why
Don’t write it’s a bug fix – most people will know it from look either at the code or in the issue tracking system (see point 1 above), rather write why it fixes the issue (“New check to check for missing parameters”, “Now handles no search result from db correct” – not just “bugfix”).
Keep it brief.
Log messages are not a place to store documentation, user guides or any other important information. You can assume it’s the future you (or another future fellow developer) who will look at the code and try to make sense of it. Think of this, when writing the message – it’s not for the project manager, it’s not for the end-users – it’s for a developer doing maintenance work on the code in the future.
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.
CVS is a sourcecode version control system, which is just about the best thing which can ever happen to a software project. CVS gives you the power to manage the development of your sourcecode and keep track of changes in the code.
Below there’s a few pointers to the net, where you can find lots of information about CVS and the add-on tools which supplies it. The section called “local content” is our own attempt to add something to the endless pages describing and explaing how to use CVS. Enjoy.
CVS Documentation and Information
- General resources:
- Documentation and Guides
- Tutorials and Training
CVS Tools and add-ons
To accompany CVS a large number of tools exist. Below is a brief list of those found most useful.
Other sources of information