Nordlicht Reisen GmbH, a fictional travel agency, has so far developed its booking portal like this: every person works for weeks on a branch of their own, and shortly before the deadline the branches are merged. Merging takes a day every time and regularly breaks something. Now the team is growing, and a second version of the portal for a partner has to be maintained in parallel. You are to design a branching strategy that fits both.
The exam calls this skill Design a branch strategy, with the keywords trunk-based, feature branch and release branch. It is not about Git commands but about a decision with reasons.
Prior knowledge: What a commit, a branch and a pull request are, and how you use a repository on GitHub and on Azure Repos, you know from K3, lessons 3.7.1 and 3.7.2 (that is where the pipelines that hang on branches come from). How versions arise from Git tags is in K3, lesson 3.7.4. This lesson begins where the subject is no longer a repository but the rules of a team. The pull request flow with protection rules is taught by the next lesson (2.2).
What a branch costs
A branch in Git is cheap: Microsoft writes in the guidance on the branching strategy that branches are "inexpensive to create and maintain". Something else is expensive, namely the time a branch lives apart from the rest of the code. Microsoft's guidance on choosing a strategy explains why branches should be short-lived: that keeps merge conflicts as rare as possible. It also advises branching only when necessary, because changes in DevOps are continuous and frequent and merge conflicts often have to be resolved by hand. Instead of branching, you should rely on other means such as feature toggles.
From this follows the frame for everything else. Every strategy consists of three building blocks that you mix:
| Building block | What it is | What it costs |
|---|---|---|
Trunk (main branch, main) |
the one branch that always builds and is up to date | Discipline: it must never be broken for good |
| Feature branch (topic branch) | short branch for one change, goes into the trunk by pull request | Merge debt if it lives long |
| Release branch | branch for a shipped version, is not merged back | every active version is one more state that you maintain |