Lesson220 words
Designing a branch strategy
Design a branch strategy
| Strategy | Shape | Suits |
|---|---|---|
| Trunk-based | Everyone commits to main, very short branches | Continuous delivery, strong test coverage, feature flags |
| Feature branch | One branch per unit of work, merged by PR | Most teams; the default |
| Release branch | A branch per released version, patched independently | Multiple supported versions in the field |
The real decision
Branching strategy is chosen by how many versions you must support in production, not by team preference.
- One version live → trunk-based or feature branches. Nothing needs to be patched separately.
- Several versions live → release branches, because you must fix v2.3 without shipping v2.4's changes.
Everything else — branch naming, PR size, review policy — is secondary to that question.
Long-lived branches are the cost
Every long-lived branch diverges, and merge pain grows with time and distance. That is the argument for short-lived branches and, where work spans cycles, for feature flags instead of a branch: the code merges continuously and stays dormant.
Where policy fits
A strategy is a diagram until it is enforced. Branch policies (Azure Repos) and branch protection rules (GitHub) are what make main genuinely protected rather than protected by convention.
Primary sources