Trunk-based development

Overview

Trunk-based development is a workflow where every developer integrates into a single shared branch — the trunk (usually main) — at least once a day. Branches, if used at all, are tiny and live for hours, not weeks. It is the workflow behind true continuous integration and is favored by teams that deploy frequently.

The core idea

The further your code drifts from everyone else's, the harder integration becomes. Trunk-based development attacks that problem directly by keeping the gap tiny: you merge to the trunk constantly, so conflicts are small and caught immediately. There is no long-lived develop branch and no big-bang merges.

A typical cycle is short:

git switch main
git pull
git switch -c quick-fix
# ...a few hours of work...
git switch main
git merge quick-fix
git push

Some teams skip the branch entirely and commit straight to main behind review tooling.

Feature flags: shipping unfinished work safely

If everyone merges to the trunk daily, how do you handle a feature that takes two weeks? The answer is feature flags. You merge the incomplete code, but keep it switched off behind a runtime flag:

if (featureFlags.newCheckout) {
  renderNewCheckout()
} else {
  renderOldCheckout()
}

The code travels to production hidden, and you flip the flag on when it is ready. This decouples deploying code from releasing a feature.

What it demands

Trunk-based development is fast, but it is not loose — it only works with strong supporting practices:

• Robust CI: every push runs an automated test suite, because a broken trunk blocks the whole team.
• Small, frequent commits: large changes are broken into safe, incremental steps.
• Feature flags for anything that cannot be finished in a single short-lived branch.
• Fast code review, often via small pull requests that merge within hours.

Trunk-based vs Gitflow

Gitflow optimizes for controlled, versioned releases with many branch types. Trunk-based development optimizes for speed and continuous delivery with essentially one branch. If you deploy several times a day, trunk-based fits; if you ship versioned releases on a schedule, Gitflow's structure may serve you better.

Practice