Know Your Branch Types

Common names for code branches helps you figure out your codeline model

I’ve come across quite a few conversations about the challenges with codeline models that involve branching and pull requests. These often end with an assertion that branching is the primary cause of these challenges. Once reason that I don’t fully agree with that assertion is that the conversations often conflate various kinds of branches, and disconnect the concept of a branch from a work stream.

Having multiple divergent work streams adds overhead to a project. But having multiple work streams is a basic element of team collaboration, and in many cases the the overhead is worth the overhead. The key thing is to keep the time to integration short.

What often gets lost in these conversations is that work in a developers workspace is also a divergent work stream, much like a branch in terms of impact, but less like one in terms of transparency.

As I was trying to get my head around this question, I tried to classify some of the branches that Software Configuration Management Patterns covers. It may not be perfect, but the following table gives a high level view of how the attributes of purpose, lifetime, number of contributors, and final disposition relate to some common kinds of branches you might use.

This table skips one the the Patterns in the book: Release Prep Code Line. While “branch instead of freeze” is 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.

As a general rule, having short lived work streams that get merged into the Main Line is the best approach. A Task Branch, which has a short lifetime is is worked on by a developer (or pair) is a reasonable way to organize this work. The Main Line model favors limiting yourself to a Main Line, and a Task Branch for most work.

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

Feature Branches are best avoided, as they add a lot of overhead and break developer flow.

Having clear definitions isn’t enough to solve the problems you might be having on a team, but hopefully it can facilitate better solution seeking conversations. And if you don’t agree with my set of attributes, do the same exercise with your own. Team development depends on communication, which is rooted common understanding of concepts.

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. I’ll discuss this in a later post.