DEVOPS-01-004-P · Primer — Trunk-Based Development

The idea in one sentence

Trunk-based development is the practice where every developer merges small changes into one shared branch — the trunk — at least once a day, instead of hoarding work on a long-lived branch.

Why it exists

Branches rot. The longer a feature branch lives away from the trunk, the more the trunk moves underneath it, and the cost of merging back does not grow linearly with branch age — it explodes, because every conflict must be reconciled against weeks of other people's changes. Picture a feature that sits on its own branch for three weeks while the trunk absorbs four hundred commits from everyone else; the "big bang" merge back is a different world from the one the branch forked from, and a regression can slip in during the chaos of untangling it. Trunk-based development exists to make that merge disappear: keep every integration small and continuous so conflicts stay tiny and are caught the moment they appear. It is the enabling practice for continuous integration — you cannot continuously integrate if everyone is sitting on their changes.

How it works

Every commit goes to the trunk (directly, or via a pull request branch that lives hours, not weeks) and triggers the CI pipeline: build, then test. Green means the change is integrated; red means you fix it now, not three weeks from now. Work that is not finished does not hide on a branch — it hides behind a feature flag: the incomplete code ships to production turned off, so it is merged but not released, and you flip the flag from 0% to 100% when it is ready. That single move — decoupling "merged" from "released" — is what lets a whole team share one branch without shipping half-built features, and the DORA/Accelerate research found that trunk-based development (fewer than three active branches, each living less than a day, no long code freezes) is a statistically significant predictor of elite delivery performance.

See it — merge small, integrate daily, release behind a flag

flowchart LR
    A["Small commit"] --> B["C.I. build + test"]
    B --> C["Merge to trunk<br/>same day"]
    C --> D["Unfinished work<br/>hidden by a flag"]
    D --> E["Merged, not released"]
    E --> F["Flip flag<br/>0% to 100%"]

The one gotcha

Short-lived branches plus feature flags beat long-lived branches that rot and conflict. The instinct is that an isolated feature branch is safer because your work is walled off — but isolation is the disease, not the cure: isolated work silently diverges from everyone else's, and the divergence compounds every day it lives. The fix is to merge daily and gate visibility with a flag instead of a branch. But flags are not free either — a flag left on forever forks your product into two code paths nobody fully understands (exactly the failure in Drill 58), so every flag is born with a named owner, a deadline, and a deletion ticket. Trunk-based development trades merge debt for flag debt, and only pays off if you retire the flags on schedule.

See it (visualization plan)

A TimelineScene shows a three-week branch rotting as the trunk takes 400 commits; a TilesScene lands the merge tax (60 conflicts · 25 files · 2 days); then a BigNumberScene drives a flag from 0 to 100 to show "merged, not released."

The one-line takeaway

Merge daily behind a flag; never let a branch rot.

Where you'll meet it

You will live this in short-lived pull requests on GitHub or GitLab with branch protection on main, CI on every push through GitHub Actions, and feature flags in LaunchDarkly, Unleash, or OpenFeature — with Terraform keeping environments identical and Prometheus and Grafana watching each flagged rollout. Google and Meta run enormous monorepos on exactly this model, and trunkbaseddevelopment.com plus the DORA/Accelerate findings are the canonical sources for why it works.

Named concepts: trunk-based development, short-lived branches, feature flags, continuous integration