A good developer always versions his or her code. And all good version control systems provide means to create branches. On some version control systems like Subversion and git the cost of creating a branch is minimal. On others like Perforce and Visual Source Safe the cost of creating a branch on the server can be quite expensive. However if your code is not corralled by a good branching strategy you will soon have a unmanageable mess on your hand. I believe a good branching model can be developed individually for each project based on its needs and workflow. However some of the commonly used branching models can be used as guides to establish basic branch and merge policies. These can then be fine tuned per the need of individual projects.
In big corporations I have usually seen dedicated groups of Release Managers( and I belong to such a group) who act as gate keepers and are in charge of creating branches for developers. Developers are not given access to create branches. In smaller or medium shops, I have seen developers have open access to create branches as they please. So right off the bat, the question is who should create branches ? I believe the answer is no one. The process should be controlled by self-service and automation. This will ensure uniform enforcement of policies like naming convention, metadata management, branch history retention, tagging and any other external requirements for e.g. entry into a bug management system. Once the branch creation automation is in place you can think of one of these many policies to get you started.
Stable Trunk
In the Stable trunk model, the trunk or the main branch or the master branch remains stable. No development or checkins happen on this branch and no one but the gatekeepers are allowed to touch this branch. All development happens on branches that are created off the main branch. Once a stable build is achieved off the main branch and a milestone is achieve in terms of release, bug fix or a patch that branch is merged back into the main branch. If multiple branches are created from from the main branch and work is in progress on them then the merged branch will be merged in all the active branches. This always guarantees the stability of the main branch.
Unstable Trunk
In unstable trunk model, all the development happens on the master branch. All the developers checkin their code on the main branch and the stability of the main branch cannot be guaranteed. Release branches are created usually around the time of release to stabilize the release from the main branch and commits are merged from the main branch selectively. Now this may sound a bit messier than stable trunk but this required more rigor and discipline on the developers part so as not to break the trunk. Continuous Integration is also leveraged heavily to ensure the trunk never breaks and developers test their commits before checking them in.
Agile Development Method
With this development method individual feature branches are created from the main branch early on and feature development is done individually on each branch. A release branch is created late in development on which individual feature branches are merged to create a particular release that is then deployed to production. A separate integration branch can also be create to test the stability of release and for continuous integration. Once a milestone build or release is achieved, the release branch is merged back into the master branch and the process is repeated for the next sprint.
Private Branches or Branch Per Developer
Depending on which VCS you use this may be a good or a bad idea. In SVN this can be used as a backup or for code reviews. With git every repository is effectively a private branch. Conceptually however creating private branches, other than for private projects, is not a good idea.The work out well for temporary throw away tasks, however should be avoided in shared collaborative environments.
Shared Branches or Branch Per Task
These are branches created for a specific tasks and they will define your specific branching and merging model for your project. In general you should look at the deliverable of your project and model the branching strategy of your project accordingly. For e.g. if your project is a web site development and you are working in Agile fashion then perhaps you should branch per sprint even though your organization policy might state that you have to branch per release. Similarly if you are kicking off a long term project with big team involved then create a release branch off a main branch. Make sure you have sufficient automation and continuous integration in place.
This article was originally published on my website here http://www.nimkar.net/index.php/9-release-management/5-version-control-branching-models
What are your experiences with branching ? Leave me a comment below.