Perceived Safety and Branches

Branches are often used with the goal of improving stability. This going wrong is often the source complaints abut the use of branching. This post briefly examines the rationale behind branching some non Main Line branching strategies.

A reason teams often give for branching strategies other than working off of the Main Line is stability. The use of Feature Branches, multiple Release Lines and the Git Flow Branching Model, is often based on the principle of batching work on intermediate branches before integrating with the Main Line. The goal of these strategies is to minimize risk by maintaining the health of the Main Line by introducing change in discrete batches rather than more continuously. The resulting slower rate of change on the Main Line does decrease the risk of instability of the Main Line in the short term but moving slowly can be risky.

Among other things, batching changes increased the risk of merge conflicts, which both take longer to manage and require context shifts as team members try to recall the context of the conflicting change. As the time to integrate changes increases, product evolution rates decrease. This can create market and schedule risks.

A better approach is to integrate smaller changes more quickly. Working in this way does force the team to collaborate more actively, as diverging approaches become visible more quickly. This doesn’t come for free; you need to develop processes that include automated testing and committing changes in small batches. However, in the end your time to integration and quality will get better.

Moving slowing gives you an illusion of control. You will still see conflicts that and work that breaks existing code. Finding these quickly make them easier to fix. When a process is broken we are often tempted to do something, even if we’re not sure that it is the right thing. Imposing rules and processes seems like positive action, but more often than not, the control is illusory. It’s better to work to address the underlying issue: incremental quality.

Agile teams work best when they acknowledge that there is risk in deferring change. This means focusing on processes that improve the time from code change to delivery so that feedback can happen quickly, and when there is a problem, teams can fix it immediately.

Next up: why we should focus on integration time rather than if we use branches