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 also8
Branching Model
The convention governing what branches exist, what they mean, and how work reaches production.
Version Control & Delivery18 connections
Merge Train
Validating changes against the state they will actually merge into, in order, rather than in isolation.
Version Control & Delivery14 connections
Squash Merge
Collapsing a branch's commits into one before merging, trading granularity for a clean main history.
Version Control & Delivery24 connections
Pull Request
A proposal to merge a branch, carrying review, automated checks, and the discussion around it.
Version Control & Delivery25 connections
Three-Way Merge
Combining two lines of work by comparing both against their common ancestor.
Version Control & Delivery17 connections
Documentation Rot
Documentation that has drifted from the system it describes, and is now worse than none.
Method28 connections
Fast-Forward Merge
The two basic ways Git joins branches, by sliding a branch pointer forward or by recording a new commit with two parents, and how the choice shapes a project's history.
Version Control & Delivery14 connections
Cherry-Pick
Copying the change from one commit onto another branch as a new commit, the standard way to backport a fix without merging everything else that came with it.
Version Control & Delivery15 connections
Linked from19
- Branch ProtectionVersion Control & Delivery
Server-side rules that stop people from pushing straight to important branches, requiring reviews, passing checks, and intact history instead.
- Branching ModelVersion Control & Delivery
The convention governing what branches exist, what they mean, and how work reaches production.
- Cherry-PickVersion Control & Delivery
Copying the change from one commit onto another branch as a new commit, the standard way to backport a fix without merging everything else that came with it.
- 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.
- Conway's LawVersion Control & Delivery
Systems tend to reproduce the communication structure of the organization that built them.
- Fast-Forward MergeVersion Control & Delivery
The two basic ways Git joins branches, by sliding a branch pointer forward or by recording a new commit with two parents, and how the choice shapes a project's history.
- Feature BranchVersion Control & Delivery
A branch created to develop one change in isolation before merging it back, a workflow that keeps the main line stable but grows riskier the longer the branch lives, since its divergence from everyone else's work compounds.
- Feature FlagData & Content
A runtime switch that decouples shipping code from enabling behavior.
- Git StashVersion Control & Delivery
Git's shelf for uncommitted work, which clears the working tree so you can switch tasks, and the reasons a throwaway commit or a second worktree is often the better shelf.
- HotfixVersion Control & Delivery
An urgent fix shipped outside the normal release flow, how teams branch and backport it, and why the healthiest hotfix process is the normal process run fast.
- 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.
- Release TrainVersion Control & Delivery
Shipping on a fixed schedule whether or not a given feature is ready, so features that miss one release simply wait for the next instead of holding everyone back.
- 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.