Branching to Distraction

Since software systems are complex, all but the most trivial changes will require that you extensively test the software before you ship it. You might overestimate how much delivering from a branch saves you, but having good automated test coverage can make this easier. Good automated test coverage can also reduce the need to branch, as discussed below.

Creating a branch will add some infrastructure work (creating a new continuous build, for example). Working on a branch also delays integration with the main code line.  
When you are working on a change that you will need to migrate to the main line, you have two choices:

• Integrate frequently between the branch and the main line as the work is being done.
• Wait until the work is done on the branch and attempt to integrate later.

Frequent integration has the advantage of identifying integration issues quickly, but the disadvantage of requiring the person doing the merge to shift context frequently. Merging after work is done simplifies the context-switching overhead, but a rapid rate of change on the main line can complicate the merge task.

This problem becomes more complex the longer the time between the branch point and the fix. And, regardless of which approach you choose, you’ve added complexity and risk to even the smallest change to the branch. If changes to a branch do not need to be merged, branching will be simpler, but there is still a context switch and effort being diverted from the next project.

Using branching to provide stability and isolation is based in a development model that assumes fragile and inflexible code, and it is possible that your code is not as stable or flexible as you’d like it to be. In this case, branching can be a way to enable you to keep your code working until you can make it agile. As you establish development practices that help your code be more agile, you can use branches in a way that has less impact on your ability to deliver code.