Branching and Merging

Branching is how engineers work in parallel without destroying each other: each line of work proceeds on its own branch of the codebase, and merging recombines them. The strategy a team chooses — how long branches live, how they integrate — quietly determines its release cadence, its risk profile, and how often someone's week is lost to a merge conflict.

What It Is

A branch is a parallel line of development created from the shared codebase: work proceeds independently, and the branch is later merged back, with conflicts (the same lines changed differently) resolved manually. Branching strategies sit on a spectrum: long-lived branches (develop in isolation for weeks — risky: divergence grows, merges become projects) versus trunk-based development (small changes merged to the main line within a day or two — safe: divergence never accumulates). Feature flags (see separate entry) often replace long-lived branches as the way to keep unfinished work out of users' hands. Release branches stabilise a version being shipped while development continues.

Why It Matters to You

This is deep engineering mechanics with visible executive consequences. Branching strategy sets the floor on lead time: teams on long-lived branches cannot ship quickly no matter how hard they sprint, because the merge queue is the real bottleneck. Merge frequency also predicts defect behaviour — big, old merges break in ways nobody can bisect; small, frequent ones fail tractably. If a vendor or team cannot explain their branching strategy in one sentence, that is itself information: the discipline is either absent or accidental.

When You'll Meet It

Rarely directly, but its symptoms constantly: 'we're merging this week' as a project phase, releases that slip for 'integration', hotfixes that regress. Those are branching-strategy failures wearing schedule costumes.