The Trouble with Branching

Code Lines defined terms, Why Code Lines Matter motivated why SCM Process matters, and the post addresses a major risk people see in using branching.

Branches can be a tool to support collaboration and manage risk, but branching can sometime impede collaboration and create risk. The difference in outcome is frequently related to whether people choose to branch based on habit, or based on a consideration of the costs and benefits of the approach.

A branch is a diverging code stream. If the Main Line has the latest code, creating a branch off the Main Line means that there is work that isn’t being integrated immediately. That isolates those working on the branch from needing to worry about disrupting the Main Line. It also isolates the Main Line from disruption. This can improve flow in the short term. It also provides the opportunity for each stream to explore new ideas without immediately disrupting the main Code Line, which can advance technical progress.

However diverging also means splitting the team’s attention while the work is happening, and interruption in focus when you try to integrate the work with the Main Line. This is particularly true when there are many, long lived, parallel streams. Branching can be distracting and diverging work that goes on for too long adds costs and risk.

The lesson is to be wary when you have long lived branches or complex integration policies. But don’t just avoid branching because it can go wrong. Branching can and should be used thoughtfully, and can help your flow. Remember that Branching adds overhead, but it can also reduce friction in your development pipeline as a step along the way to building out a robust agile process.

One common reason people branch too often and too long is to create a sense of safety — for example because your testing doesn’t reliably provide for integration at a good pace. Creating integration gates will slow you down, which creates more time for verification activities. But moving slowly isn’t always safer. I’ll discuss that in more detail shortly. But first I’ll discuss a risk that teams ignore that has nothing to do with branching, but which has the same profile of delayed integration.