A Taxonomy of Branches
"What is this branch for?"
While code in a development workspace is kind of work stream, in many cases teams use branches to back their development work streams. Each divergent work stream adds overhead to the project, whether it’s backed by a branch or not, and in some cases the way you use branches can add more overhead. In some cases, the overhead is worth the value of having a branch. To make a decision about whether a branch makes sense you need to understand why you have a branch. One way to think about branches is by considering the following attributes:
Purpose: the reason for creating a branch. If you can’t explain why, then you probably should not create the branch.
Lifetime: how long the branch exists.
Contributors: who on the team pushes changes to this branch under usual circumstances.
Final Disposition: What happens to the branch when you are no longer actively updating it.
The following table looks at some of the branching patterns in Software Configuration Management Patterns through the lens of these attributes.
Based on these attributes, in particular, purpose, you can evaluate whether a kind of branch makes sense. Release Prep Code Line is an example of a code line makes sense in the context of an organization that had code freezes. In the context of modern software development, a “branch instead of freeze” approach to makes little sense. While this was a reasonable transitional approach when we first gathered the patterns, the state of DevOps tools and techniques, including test automation has generally made it less desirable, and hopefully unnecessary.
The best approach is having short-lived work streams that get merged into the Main Line. A Task Branch is a reasonable way to organize this work. Contrast this to a Feature Branch, which is a longer lived branch, which is about completing a large to medium sized bit of work. Feature Branches are best avoided, as they add a lot of overhead and break developer flow. Task branches can facilitate developer flow and improve collaboration if they stay short.
A Release Line can be useful in limited situations, such as applying small critical fixes between development iterations if your process doesn’t support releasing from the Main Line with confidence (something we all work towards, but may not yet be ready for).
Another option is to have the code in your workspace interact directly with the Main Line. This approach will mean no tool overhead, but the code in your workspace in an (invisible) branch, and you lose any opportunities to leverage the collaboration and quality tools that branching enables.
The right answer will vary based on your team. Rather than starting with “which branches should we use (or not use), asking “why are we branching?” (Or “why are we not branching) is essential to having an effective approach to your codelines and work streams.
How you organize your work streams, and whether you branch or not, and if you do, how you branch, is not the only factor in determining how quickly you integrate. There are some other issues around why collaboration with multiple work streams doesn’t work well. Many of these issues involve decisions the team makes before development starts, including:
Planning (so that you can plan to work in a way that facilitates frequent integration)
Architecture and coding practices, so that the code you are working in makes it easy to deliver in an agile fashion.
Culture (so that mistakes that might happen in an attempt to deliver quickly are viewed as opportunities for improvement)
The branches, and branching model you use can establish default patterns of work. Ideally, they fit with your goals, and the factors above support them. I’ll discuss some commonly used branching models next.
Visit my web site to see the current state of the codeline patterns. And the original Software Configuration Management Patterns book is still relevant.