gitmergeversion-controlbranchtrunk

Purpose of the master branch when branching by rule

From the article Source Control Done Right:

With the “create branch” button just a click away, there are a plethora of ways to incorrectly branch your codebase. But there are only two correct strategies – branching by rule and branching by exception – and both are related to isolating changes in releases. Because of this, a branch should always be identified by its corresponding release number.

The reason for this is simple: there’s only one trunk (mainline, root, parent, or whatever you want to call it), and the code under that trunk is either what’s in production now (the last deployed release), or what will be in production later (the next planned release). And that means you’re either always branching or only branching sometimes.

Branching by exception strategy

Branching by rule

When you have to maintain multiple release versions of a software product in parallel (which is common unless you have a software-as-a-service delivery model), the branching by rule strategy seems the most appropriate*. But in this situation, if you use continuous deployment of all the tags of each release branch in a dedicated environment (for instance you automatically deploy all the 2.2.x tags in a 2.2 environment and all the 2.3.x tags in a 2.3 environment), all the tags of each release branch will also be automatically merged into the master branch since the master branch is supposed to reflects what is in production. This will cause merge conflicts if the tags of different release branches are interleaved in time (for instance in the branching by rule diagram above, this tag sequence would be merged into the master branch if continuous deployment was used: 2.2.1, 2.2.2, 2.2.3, 2.3.1, 2.3.2, 2.2.4, 2.3.3, 2.2.5, etc.; but since continuous deployment is not used, only the last tag of each release branche is deployed and therefore automatically merged into the master branch, so there is no such issue).

So when using the branching by rule strategy, what is the purpose of using the master branch? It looks to me that the master branch only makes sense for software products which have a single release version at a time and exceptionally more, that is to say when using the branching by exception strategy.

* The Github repository of the CPython interpreter is an example using the branching by rule strategy.

Solution

  • This question has no universally true answer, because it is based on a subjective article that almost a decade ago suggested using just two strategies for branching. Note, that at that time SVN was still a king and creating branches was expensive there - so not many people thought about using lot of branches just because they wanted so (but some did).

    Since then many things changed and a lot of teams adopted other strategies - for example, git flow branching model, which de facto became one of industry standards. In that strategy all the branching happens off development branch, while master is merely used as a stable backup.

    Anyway, that ^^^ is just to explain, that the referenced article is not a law, but rather author's vision. The article might be wrong or incomplete (well, it is incomplete, because it doesn't include git flow, which was suggested a year earlier). If you see a problem there - it might be indeed a problem, not your lack of understanding.

    Answering the question:

    When using the branching by rule strategy, what is the purpose of using the master branch? It looks to me that the master branch only makes sense for software products which have a single release version...

    Yes, using master branch actively makes most sense for the products with a single release version. Indeed "software-as-a-service" (say "website") is the best model for that. That branching strategy needs improvements if in your product model there might be different customers on different versions of the software simultaneously. In that case you will need to come up with a more sophisticated scheme.

    However, even with the parallel versions model master is still needed. It is a stable branch with all the features you ever developed. Its usage is infrequent but important - it serves as a starting point for the new version, when the product managers decide to begin developing a new set of features. And that's also the reason why your strategy should require merging released branches back to master regularly - presumably after each release. Contrary to the picture, the merge to master wouldn't end the life of those branches. Rather it would be a sync of improvements to let master stay current and continue being the proper source for the further development iterations.