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.
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.