DEVOPS-03-003-P · Primer — Trunk-Based Development & Merge Frequency

The idea in one sentence

The "integration" in continuous integration means every developer merges small changes into one shared trunk at least once a day — not just that a build runs.

Why it exists

When the term "CI" was coined, the hard problem wasn't compiling code — it was combining everyone's work. Imagine four developers who each disappear onto their own branch for three weeks. On paper each branch works. But while Amir was editing the payment module, Bea renamed a function it calls, Chen restructured the database it reads, and Dana deleted a config it depends on. None of them saw the others' changes. The day they finally merge, all four sets of conflicts, renames, and hidden assumptions collide at once. Days vanish untangling it. That painful, drawn-out merge is what practitioners call integration hell, and it gets exponentially worse the longer branches drift apart.

Trunk-based development exists to make that pain impossible by never letting the gap grow large. If everyone merges tiny changes into the shared line daily, conflicts stay small enough to resolve in minutes while the context is still fresh. Google's DORA research found this measurably matters: teams that keep three or fewer active branches, merge to trunk at least once a day, and avoid code freezes and integration phases deliver software faster and more reliably. Merging frequently isn't bureaucratic hygiene — it's the mechanism that keeps integration cheap.

How it works

There is one long-lived branch — the trunk (also called main or master). Everyone treats it as the single source of truth.

1. Take a small slice. You break your task into a change small enough to finish in hours, not weeks — ideally something that keeps the trunk working even if the feature isn't visible yet.
2. Work on a short-lived branch. You may branch off trunk, but that branch lives less than a day. (Some teams commit straight to trunk.)
3. Pull the latest trunk first. Before merging, you update from trunk so you're integrating against everyone else's newest work, not last week's.
4. Merge back into trunk — at least daily. Small change, small merge, small blast radius.
5. Fast automated tests run on trunk. After each merge, the test suite runs. If it breaks, you fix it immediately, because a broken trunk blocks everyone. This step is what turns "we all share a branch" into true continuous integration.

Because each merge is small and frequent, merge frequency stays high and each individual merge stays trivial. To ship a feature that isn't finished yet without leaving trunk broken, teams hide unfinished work behind feature flags — an if-statement that keeps new code switched off in production until it's ready.

The one gotcha

"Our CI pipeline is green" does not mean you're doing continuous integration. A green build only tells you the code that was merged compiles and passes tests. If that code sat on a branch for two weeks before merging, you've delayed integration hell, not avoided it — the giant merge is still coming. Continuous integration is measured by how often you merge into the shared trunk, not by whether a build server exists. A CI server running against long-lived branches is just automated testing on isolated islands. The daily merge is the part that actually counts.

See it — daily small merges vs. one giant late merge

flowchart TD
  subgraph TBD["Trunk-based (merge daily)"]
    A["Small change"] --> B["Pull latest<br/>trunk"]
    B --> C["Merge to trunk<br/>(tiny conflict)"]
    C --> D["Tests run<br/>on trunk"]
    D --> E["Trunk stays<br/>healthy"]
  end
  subgraph LATE["Long-lived branch"]
    F["3 weeks of<br/>solo work"] --> G["Branches drift<br/>apart"]
    G --> H["One giant merge<br/>(integration hell)"]
    H --> I["Days of<br/>conflict fixing"]
  end

The one-line takeaway

Continuous integration means merging small changes into a shared trunk every day — high merge frequency is what keeps integration hell from ever forming.

Where you'll meet it

You'll meet trunk-based development the first time you're told to "rebase off main before you merge" or asked why your two-week-old branch has fifty conflicts. You'll meet merge frequency in DORA metrics and team retros ("we have too many stale branches"). And you'll meet integration hell the hard way if a feature branch lives long enough to drift — the fix is almost always to merge smaller and merge sooner, often behind a feature flag.

Named concepts: trunk-based development, merge frequency, integration hell