Part 5 · 2 chapters · ~12 min
Merge Strategies and Branch Protection
Merge commits, squash and rebase merges and the history each leaves, trunk-based development with short-lived branches, protected branches, required checks and reviews, merge queues, signed commits, and reverting safely.
10
Three strategies
Trunk-based development (Books: Accelerate) favours short-lived branches merged at least daily; long-lived branches create painful merges and delay feedback, whatever the strategy.
MERGE, SQUASH, REBASE
three ways to land a branch, and the history each leaves
swipe the figure sideways, or tap expand for full screen
1/4
merge commit
A merge commit keeps every branch commit and records when the branch joined. Complete history, but noisy with "fix typo" commits, and a non-linear graph.
full history, non-linearnoisy with WIP commits
11
Protection and merge queues
| setting | why |
|---|---|
| protected main: no direct pushes, no force pushes | every change is reviewed and checked |
| required status checks (tests, lint, types, build) | broken code cannot merge |
| required reviews, with CODEOWNERS for sensitive paths | the right people see the right changes |
| dismiss stale approvals on new commits | approval matches what is merged |
| merge queue | each PR is tested against the latest main plus PRs ahead of it, so main stays green under high merge volume |
| signed commits (optional) | provenance for sensitive repositories |
Reverting: with squash merges, git revert <sha> undoes a whole PR cleanly. Revert first, investigate second, when a merge breaks production.