Trunk-Based Development

Trunk-based development keeps every engineer committing to one shared mainline at least daily, using short-lived branches, feature flags, and continuous integration to avoid merge hell.

delivery

Definition

Trunk-based development is a branching model in which all developers integrate into a single shared trunk at least once a day, keeping branches short-lived or absent and relying on automated tests and feature flags to keep the trunk releasable.

Context and scope

Used by teams that deploy continuously and want to reduce merge conflicts, long-lived branch divergence, and integration risk.

Common misconceptions

Trunk-based development bans all branches; it only bans long-lived divergence
It skips code review; review still happens, often earlier and on smaller changes
It only works for web teams; any team with automated verification can adopt it

Anti-patterns

Maintaining a branch for weeks and calling it trunk-based because it merges to main
Committing daily to a trunk whose CI suite is flaky or ignored
Hiding unfinished work behind flags that nobody ever removes

Related concepts

Authoritative source

https://trunkbaseddevelopment.com/

How it works

Trunk-based development treats main as the only long-lived branch. Engineers rebase onto the latest trunk, commit small slices, and push at least once a day. Working branches live for hours, not weeks. Continuous integration runs on every push, and unfinished work hides behind feature flags so the trunk stays releasable. Releases are cut directly from the trunk.

When to use it

Use it when the team deploys continuously, the automated test suite is fast and trustworthy, and engineers can ship small changes behind toggles. It fits product teams with shared code ownership. Compared with feature branching, it trades isolation for integration frequency: conflicts surface early and cheaply instead of late and painfully.

Trade-offs

The model depends on strong CI, meaningful test coverage, and disciplined flag cleanup. A flaky suite or slow review turns daily integration into daily breakage. Reviewers must respond quickly because small commits pile up fast. Regulated teams can still cut short release branches from the trunk, but those are artifacts, not workspaces.

Example

A developer fixes a checkout bug: rebase, commit a forty-line change, push, watch CI pass, and merge within the hour. A larger redesign ships dark behind checkout_v2 and is enabled for internal users first.

Misconceptions

Trunk-based development does not ban branches; it bans long-lived divergence. It also does not skip review: review moves earlier, into pair programming or small pull requests. Another myth is that it only suits web teams; any team with automated verification can adopt it.

Feature branching isolates work but delays integration; code review keeps small trunk commits safe; progressive delivery controls exposure after merge.