Branching and Integration Time

Discussions about branching often focus on the wrong thing. Unintegrated code sitting around slows teams down, whether the code is in a branch or in a developer’s workspace. Discussions about improving pace of development often veer into arguments about branching. Arguing about whether branches are good or bad will distract you from the more basic question of “Do changes get integrated and tested rapidly enough to ensure the rate of delivery we want?”

Integrating too slowly is the main challenge to agile development. Slow integration makes it harder to show incremental progress and maintain an always working code line with valuable features. Frequent integration helps the team deliver incrementally and maintain working software. Your process should help you to integrate quickly so that you can deliver value at a good pace.

The ideal integration frequency varies from team to team. Merging once a day is good, more frequently can be better, but too often can cause churn and overhead if you aren’t doing it well. Team and planning dynamics are key decision factors, but some things are universally true: small frequent commits improve reliability, changes that move the design forward are more valuable than trivial changes. These factors often lead to once a day as a good initial target, but each team needs to decide what values of “small” and “frequent” work for them. (Retrospectives are a good forum for exploring that question.) Automated testing is essential to moving quickly even though it can add a small increment of time to the commit interval in the short term.

Getting this to work well can be challenging, but it is doable. Small useful increments and effective tests are easier than many believe. Though you may need to change your mindset.

Branches and reviews can improve collaboration for both co-located and remote teams. So rather than starting with a “branch or not” conversation, start with an integration rate goal and evaluate how long it takes code to get into production. The next post will talk about why branching can have advantages for your team.

(This is adapted from an earlier Techwell article)