Cram Sheet250 words
Topic 2.1 — Branching strategies — cram sheet
Topic 2.1 — Branching strategies · cram sheet
Choosing
The deciding question: how many versions must you support in production?
| Strategy | Suits |
|---|---|
| Trunk-based | CD, strong tests, feature flags |
| Feature branch | Most teams — the default |
| Release branch | Multiple supported versions in the field |
Long-lived branches diverge; merge pain grows with time and distance.
Policy vocabulary
| Platform | Mechanism |
|---|---|
| Azure Repos | Branch policies |
| GitHub | Branch protection rules |
Can require: reviewers · linked work items · resolved comments · successful build · external status checks.
Pull request workflow
- Run machines before humans — never spend review attention on lint.
- More reviewers ≠ better review (diffusion of responsibility). Prefer code owners.
- Pick squash or merge commits and enforce it — a mixture is hard to bisect.
Merging restrictions
| Restriction | Effect |
|---|---|
| Require a PR | No direct pushes |
| Restrict who can push | Named people/teams/apps |
| Require status checks | Blocked until green |
| Require up to date | Revalidate against the current target |
| Include administrators | Rules apply to admins too |
| Block force push / deletion | History cannot be rewritten |
Two traps
- Without "require up to date", two individually-green PRs can break
maintogether. - Exempting administrators removes protection exactly when it matters — during an incident.