Development & Code · master area
Trunk-Based Development
Short-lived branches, continuous integration into main. Branches over five days are postmortem candidates — they hide context, accumulate merge debt, and drift from the chain.
Owners: Developer, Tech Lead Phase it lives in: How We Build (Volume IV) The corpus principle this enacts: The pipeline catches a different chain level at each stage — and only catches what main contains.
Where it lives in the chain
- How We Build · The Pipeline — three environments, trunk-based
- How We Build · Commit discipline — what trunk-based discipline looks like at commit granularity
How to do this
- Practice — story branches live 1–3 days. Anything longer surfaces in the daily standup. Five-day-old branches are escalated.
- Practice — feature flags wrap unfinished behaviour so trunk can carry it without exposing it. Merging is decoupled from releasing.
- Related craft — Feature Flag Implementation — the discipline that makes long features compatible with short branches
What good practice looks like
A story is pulled. A branch is cut from main. The first commit goes up within hours, not days — even if it's a skeleton. The branch is rebased on main, not merged from main, so the history stays linear. Continuous integration runs every push — the chain of catches starts working immediately, not at PR time. PR review happens in a day, not a week. Merge to main, branch deleted same hour.
The chain's guarantee is: main is always shippable. A long-lived branch breaks that guarantee silently — main thinks it's healthy because it hasn't seen the diverged work yet. Trunk-based is not faster development. It is honest development. The team always knows what they have.
Related crafts
- Feature Flag Implementation — the unlocker
- Code Review — must be fast for trunk-based to work
- Conventional Commits — the commit shape that supports continuous integration