One of the issues all development teams will face at least once and sometimes several times as the team grows is how to allow multiple versions of the code to exist in a variety of different states. The solution to this problem (as implemented within many source code management systems) is commonly referred to as “branching”. The purpose of branching as described above is to allow individuals or teams of developers to work on the same code without constantly interfering with each other. For example let’s say engineer A is working on the application’s admin module and decides to check in his work to the source code repository in order to not lose it in the event of his hard drive crashing. Unknown to him, he has a major bug in it that prevents the admin module from working properly. Engineer B wants to fix a production issue so he checks out the source code but cannot get the admin module working properly to debug the production issue because engineer A checked in a bug. This scenario and many others can be avoided by proper branching.
The term branching refers to isolating changes onto a separate line of development that does not appear on the main trunk (aka “production branch” or “release candidate branch”) of code. You can move changes from one branch to the main trunk or from main trunk to a branch by merging. Some shops avoid branching all together because of the fear of merging. While merging can be problematic there are ways to minimize this issue as well that we will address in future articles.
As with most things in software development there are as many branching strategies as there are opinions and most of them have pros and cons that make them worth discussing amongst the team. There is no single right answer for every organization, so your approach should be to choose the strategy that works best for the given the skills of the team and the toolset/systems employed. Here are two sample branching strategies that we have seen work in the past and you might want to consider.
The first strategy, for those of us who do not need the extra complexity and want a simple way to keep our code safe, follows the KISS principle (Keep It Simple Stupid). In this scenario you can use the main trunk for new development and pull a branch right after the release for maintenance. For example if you just released version 2.5 then call this new branch “2.5_maint” and use the main trunk for development of version 2.6. The “2.5_maint” branch is used only for production fixes and gets merged into the main before QA. This is a very simple and easy to understand strategy that suffices to keep a pristine copy of the code base ready for any production issues but does not overburden the engineers by making them manage too many branches and thus environments. A permutation of this strategy is to leave the main trunk as the code that is in production and pull a branch whenever you start a new release. Continuing with our example, if you currently have version 2.5 in production and are starting development on 2.6 someone would create a new branch from the main code base (trunk) and name it “2.6”. All developers working on 2.6 check out this branch and use it for committing their new features. This branch is utilized through QA until the code is ready for production and then the branch is merged into the main trunk. If there have been production fixes in the main trunk these need to be either double committed to the main and branch or merged up from the main to the branch.
The second strategy that is much more complex but tends to work well with large development teams who are releasing code at different times, typically because of an iterative SDLC, is to give each developer or pair of developers their own branch. The developer chooses their next feature and pulls a branch for themselves. When they are done coding, unit testing and sometimes feature testing right on their personal branch, they merge it into a release branch that is the gathering place for all features ready to be sent through QA regression for a near term release. The advantage of this is that features can be pulled out or added at the last minute before regression and therefore the release will have less chance of being delayed because of one feature. A modification of this approach is to have a group of developers associated with a specific release have their own branch, which in turn enables parallel development.
These are just two of the myriad strategies that exist but these or permutations of these are ones that we have seen work well in the past. Tell us your favorite branching strategy!