Git branching that survives real incidents
Updated
A boring branching model beats a clever one: short branches, revert-first culture and releases you can undo.
Branching models fail at 2 AM, not in diagrams. The model that survives is the boring one: main always releasable, branches short, every release tagged, and a team culture that reverts first and investigates second.
The three rules
Main stays releasable. Every merge into main must be something you would ship. Feature flags hide unfinished work; long branches hide unmerged risk.
Revert beats repair under pressure. A revert is one known-good step backward. A hotfix at night is an unknown step forward written by tired people. Stop the bleeding first, then fix on a branch with tests.
Tag everything you ship. A tag turns we shipped something Tuesday into we shipped exactly this commit Tuesday. Rollback without tags is archaeology.
Worked example: a fictional bad release at noon
The context below is fictional. Fictional team ParcelTrack (fictional) ships release v2.14.0 at noon; error rates triple within 20 minutes. The change list has nine commits across three features.
The responder does not read code first. They revert the release to v2.13.2, confirm the error rate flattens, then announce the revert in the team channel with the tag names. Afternoon: the nine commits are bisected on a branch, the guilty caching change is found, fixed with a test, and re-shipped as v2.14.1. Total customer impact: 35 minutes. The postmortem notes the boring truth: tags and a revert habit did more than any tooling.
Decision table: incident Git moves
| Situation | Move | Why |
|---|---|---|
| Release just broke prod | Revert to last tag | One known step back, minutes not hours |
| Guilty commit unclear | Bisect on a branch | Production stays stable while you hunt |
| Long branch conflicts | Split and merge in slices | Small merges review fast and revert clean |
Checklist: a revert-ready repo
- Every production release has a tag.
- Main has no known-broken commits right now.
- The revert command for the last release is obvious.
- The team has reverted at least once without drama.
Related reading
- Practice the revert path: Revert the Published Mistake.
- DevOps Foundations covers the Git sequence in Module 3.
Straight answers
Frequently asked questions
Trunk-based or GitFlow?
For most teams, short branches into main with tags per release. Complexity must be earned by release pain, not anticipated.
Revert or fix forward?
Revert first to stop the bleeding, then fix calmly on a branch. Production is not the place to debug under pressure.
How long may a branch live?
Days, not weeks. A branch older than a week has usually merged conceptually with everything and conflicts with everything.