Integration frequency is the lever

Two engineers fork the same OrderService on Monday. Alice ships a one-line fix Monday afternoon: her branch reconciles half a day of other people’s commits, merges in thirty seconds, done. Bob keeps his “checkout rewrite” on a branch for three weeks. On merge day, trunk has moved 600 commits under him — the validation helper he calls was renamed, the money type changed from cents-as-int to a Money class, a migration reshaped the table. His feature was finished in week two. The other week and a half is the integration tax, and he pays all of it at once.

Merge cost is a function of drift, not diff size

The intuitive model — “a big feature is hard to merge because it’s big” — is wrong in a way that matters. The cost of merging a branch is set by divergence: how far trunk has moved away from the point where you forked. A 2,000-line feature merged the same hour you started has near-zero merge cost, because trunk hasn’t moved. A 50-line fix merged after three weeks can be agony, because the 50 lines now sit on top of a foundation that was rebuilt underneath them.

Divergence compounds because integration is a shared system. While your branch is alive, every other engineer is also merging to trunk. A branch that lives one day reconciles one day of everyone else’s work. A branch that lives three weeks reconciles three weeks of it — and worse, you’ve lost the mental context for code that changed while you weren’t looking. The cost curve bends upward with branch age, not linearly. This is why Microsoft’s internal study found teams that went more than three days without integrating spent roughly 12× longer resolving conflicts than teams merging daily, and why merge-conflict work consumes an estimated 10–25% of developer time in branch-heavy shops.

Textual conflicts are the cheap ones

Git’s merge will flag a textual conflict when two branches edit the same lines — those are loud, and the tool stops you. The expensive failures are semantic conflicts: both sides apply cleanly, git is happy, and the code is now wrong. Alice renames validate(order) to validateOrder(order) and updates all 40 call sites on trunk. Bob’s branch added a 41st call site to the old name. Git merges both with zero conflict markers; the build breaks, or worse, it compiles because of an overload and silently does the wrong thing.

Semantic conflicts scale with the same drift variable. The more trunk changed while you were away, the more invisible assumptions your branch is built on have quietly become false. Frequent integration is the only cheap defense: a one-day-old branch can only have inherited one day of broken assumptions, and your CI gate catches them while the change that caused them is still fresh in someone’s memory.

Frequency is the lever; tooling is a rounding error

Teams in merge pain reach for a better merge tool first. It’s the wrong knob. A smarter three-way diff lowers the cost of resolving a given conflict, but it cannot lower the conflict’s size — that’s fixed by how much trunk drifted, which is fixed by how long you waited. Three weeks of divergence is three weeks of divergence whether you resolve it in vim or in a fancy GUI. The lever that actually moves the cost is the one that controls drift: integrate more often.

This reframes “continuous integration” away from “we have a CI server.” CI is a practice — every developer merging small changes to the shared trunk at least daily — and the server is just the gate that makes the practice safe. The batch-size principle from lean shows up here exactly: small batches expose problems early and cheaply; large batches hide them until they detonate together. A daily merge is a small batch. A three-week branch is one enormous batch you can’t unship.