Trunk-based development

Everyone integrates into one trunk — main — continuously, many times a day. Continuous integration in its original, literal sense means exactly this: each developer merges their work into the shared trunk at least daily, often several times. The trunk is the one source of truth, and the gap between “code written” and “code on trunk” is measured in hours. The reason is mathematical: divergence between a branch and trunk grows with time, so if every change integrates within hours, divergence — and therefore merge conflicts — stays tiny. TBD attacks merge hell at its root by never letting two lines of work drift apart in the first place.

Work happens in very short-lived branches or small direct commits. Branches in TBD live for hours, rarely more than a day. Many teams use a branch only long enough to run CI and get a quick PR review:

git checkout main
git pull
git checkout -b fix-rate-limit-header
# one small, focused change ...
git push -u origin fix-rate-limit-header
# fast review + green CI, merge same day, delete branch

Smaller orgs practising TBD sometimes commit directly to trunk for trivial changes (with CI gating the push). Either way the unit of work is small: a change you can finish, review, and integrate the same day. Big features are not done on big branches — they are broken into small increments that each land on trunk.

Incomplete features are merged but hidden behind feature flags. This is the load-bearing idea. If a feature takes three weeks, you do not keep a three-week branch — you merge its half-finished code to trunk continuously, wrapped in a feature flag that is off in production:

if (flags.enabled("new-checkout")) {
  return renderNewCheckout();
}
return renderLegacyCheckout();

The unfinished code is on trunk (integrated, compiled, tested against everyone else’s changes) but invisible to users until the flag is turned on — which can be a gradual rollout to 1%, then 10%, then everyone. Flags are what make “merge constantly, even unfinished work” safe. Without them, TBD is impossible; with them, branch length drops to near zero and incompleteness lives in configuration, not in git topology.

Versioned releases come from release branches cut off trunk — and only off trunk. TBD does not forbid versioning; it forbids long-lived development branches. When you need to ship a versioned release, you cut a short release branch from trunk at a chosen commit, stabilise it, tag it, and ship — but development never moves to that branch:

git checkout main
git checkout -b release/2.4
git tag -a v2.4.0 -m "Release 2.4.0"
# critical fixes cherry-picked FROM trunk INTO the release branch

The crucial discipline: fixes are made on trunk first, then cherry-picked into the release branch, never the reverse. The release branch is a read-mostly snapshot for shipping and patching a specific version; all real work stays on the one trunk. This is how TBD supports versioned products without the divergence that sank git-flow’s develop.