Trunk-Based Development
Everyone integrating into one shared branch continuously, with short-lived feature branches.
Trunk-based development is the practice of integrating all work into a single shared branch frequently — at most a day or two of divergence — rather than maintaining long-lived parallel branches. Feature branches exist but are short.
Its argument is about the cost of divergence. Merge difficulty grows superlinearly with how long two lines of work have been apart, and the difficult part is rarely textual: two branches can each be correct and combine into something broken, with no conflict anywhere. See Semantic Conflict. Short branches keep the integration problem small enough to be uninteresting.
Working this way requires the ability to merge unfinished work safely, which is what Feature Flags provide: the code ships to the shared branch and stays inert until switched on. That is a real capability to build, and it is what makes "merge daily" compatible with "release when ready".
It also requires the shared branch to stay green, which makes Continuous Integration non-optional rather than a nicety, and puts weight on fast feedback. A branch that takes an hour to validate cannot be integrated several times a day.
The practice scales down well — it is close to what a single developer naturally does — and scales up only with genuine investment in flags, testing, and deployment automation.
See also5
Hand-picked in the note itself — the neighbours worth reading next.
Branching Model
The convention governing what branches exist, what they mean, and how work reaches production.
Version Control & Delivery11 connections
Continuous Integration
Automatically building and testing every change, so integration problems surface immediately.
Version Control & Delivery17 connections
Feature Flag
A runtime switch that decouples shipping code from enabling behaviour.
Data & Content9 connections
Merge Train
Validating changes against the state they will actually merge into, in order, rather than in isolation.
Version Control & Delivery9 connections
Squash Merge
Collapsing a branch's commits into one before merging, trading granularity for a clean main history.
Version Control & Delivery10 connections
Related3
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from11
Notes elsewhere in the wiki that reach for this one.
- Branching ModelVersion Control & Delivery
The convention governing what branches exist, what they mean, and how work reaches production.
- Continuous DeploymentVersion Control & Delivery
Automatically releasing every change that passes validation.
- Continuous IntegrationVersion Control & Delivery
Automatically building and testing every change, so integration problems surface immediately.
- Feature FlagData & Content
A runtime switch that decouples shipping code from enabling behaviour.
- Merge ConflictVersion Control & Delivery
Overlapping changes that a merge cannot combine automatically, requiring a decision.
- Merge TrainVersion Control & Delivery
Validating changes against the state they will actually merge into, in order, rather than in isolation.
- Pull RequestVersion Control & Delivery
A proposal to merge a branch, carrying review, automated checks, and the discussion around it.
- RebaseVersion Control & Delivery
Replaying a branch's commits onto a new base, producing new commits with the same changes.
- Semantic ConflictVersion Control & Delivery
Two changes that merge cleanly and are incompatible in meaning.
- Squash MergeVersion Control & Delivery
Collapsing a branch's commits into one before merging, trading granularity for a clean main history.
- Three-Way MergeVersion Control & Delivery
Combining two lines of work by comparing both against their common ancestor.