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 strategy:
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.