In the past years I often reflected about how to manage source code versioning in an optimal way. Not so long ago my mental model was kind of limited due to scarce tool support (at least non-commercial ones). Using Subversion (or even CVS) isn’t what gets you to branch often. Branching isn’t that hard, but merging is. But this brings further problems. Ever since using an iterative (read agile) development approach, I encountered unfinished features (or user stories) at the end of the iteration. Since non-delivery of the completed features wasn’t an option at any time, the team had to remove the unfinished work from the product. The code remained unfinished in the repository, it was just disabled.
This isn’t a satisfactory situation by any means. Since reading the article from Henrik Kniberg about Agile version control I began to develop some ideas on the way I wanted it to be. A very similar approach is described in this post from Vincent Driessen. Vincent explains his approach based on Git, but principally it would work using any SCM. Practically only a DVCS like Git, Mercurial or Bazaar will work well. Vincent recommends using separate feature branches for every feature. This facilitates many things, especially the selective integration of features into a release. Thus at the moment of building a release the team can cherry pick every single feature it wants to be part of the release. Even finished ones can be left out for a later release. Without feature branches this isn’t possible. Scott Chacon advocates a simpler workflow which can be better suited, especially for web development.
Two things are important when using feature branches in development. First, it must be very easy to switch from one branch to another. When I say easy, I don’t mean check out the whole workspace and fire up your preferred IDE a second time. This is not what I call easy and costs way too much time. In any DVCS a branch-change is only one command in a shell. Since most IDEs and editors will automatically reload their content, nothing more is needed. The second important thing is merging. If it isn’t easy you won’t do it. But you must do it often because the other developers need to get the changes as early as possible. Furthermore a merge with 100 changesets can be painful too. So don’t let it get that big.
Not only merges should be small, changesets too should be small. Maybe you’ve heard or read the following phrase already: check in early, check in often. It should be told to everyone new to version control. This means that every finished work unit should be committed. In this way you can always track back your steps in small increments if something went wrong. Say the build just broke, it will be easier to find which line of code broke the build if the last change is small. But choose the scope of the changeset wisely. It should be as small as possible, but so large as to be self-contained and able to build. In order to get a good changeset it is useful to “know your next commit” as said by Dan Bergh Johnsson in 97 Things Every Programmer Should Know. This will lead to a very focussed working style.
We’ve seen many of the advantages of DVCS. But I haven’t told the best, you can commit locally. This means no waiting for a slow network, no problem with a server downtime and the possibility the keep a whole change history for yourself until ready to be shared. Hopefully many more companies will do the transition in the coming years, everyone will benefit greatly.
If you want to know more, the Git homepage has a very good documentation or go to hginit for an introduction to Mercurial.