Commit-policies
You use a version control system – of course you do! Personally I use Subversion (re-rolled from CVS) and no project is too small for version control imho. Both projects at work and at home go in a repository.
Even the smallest amount of programming I do go in my repository, and I wouldn’t want it any other way – the luxury of being able to roll back and forth, branching, merging and suddenly sharing with other developers if the need arise is very nice!
One of the main issues though – especially when working in a team – is how often and how much to commit. During the past few years I’ve realized a few key points:
- You can never commit too often! (Given that:)
- You should never commit code that doesn’t compile!
Following these points is easy, important and gives you very high flexibility. I bend the second rule a bit, and add the following:
- Branches are for experiments and long hard deviations, and
- Only trunk needs to be compileable at all times
This comes from the (well known) trunk/branches/tags-model which we established when we started using Subversion. We reserve trunk for the place from where we can always release a new version. Code in here should always be compile-ready – no exceptions to this rule at all!
Our branches are used for experimental development, new versions etc. and the compile-issues in here shouldn’t be to the annoyance of the other developers but generally no more than one day’s work should go in each commit (see the first rule)!
Needless to say I follow these rules very precisely all other projects, even the ones where I’m alone and working at night.
