Branching Strategies & Repo Scale

Teams don't just branch and merge at random — they agree on how, a shared convention called a branching strategy. They also decide how to organize their code across repositories. Both choices shape a developer's daily workflow, and you'll hear them named on any team.

The two big questions are: how long do branches live and how often do we integrate (trunk-based versus GitFlow), and do we keep everything in one repository or split it into many (monorepo versus polyrepo)?

A kitchen analogy: everyone plating continuously onto the same pass (trunk-based) versus separate stations whose dishes are assembled together only at the end of service (GitFlow). Both feed the guests; they feel very different to work in.

Trunk-Based Development

In trunk-based development, everyone integrates into the main line (the "trunk") often — at least daily — using short-lived branches and small changes, sometimes hiding unfinished work behind feature flags. Because work merges constantly, integration problems surface early and small, never building into a painful end-of-project pileup. It pairs naturally with continuous integration, coming in the next chapter.

GitFlow and Friends

GitFlow and similar strategies use longer-lived branches — separate ones for features, releases, and fixes — that are merged together at defined points. This gives a lot of structure and can suit scheduled, versioned releases (like packaged software). The cost is that long-lived branches drift apart from main over time, making the eventual merges bigger and more painful — the very problem trunk-based avoids.

Monorepo vs Polyrepo

Separately, teams choose where the code lives. A monorepo keeps everything — many projects or services — in one big repository; a polyrepo setup splits them across many smaller repositories. A monorepo makes it easy to change things together and see the whole picture; many repos give each piece independence at the cost of coordinating across them. Both are common; neither is simply right.

Picking a Fit

There's no universally correct choice — the right one depends on the team's size, how often it releases, and its tooling. Small teams releasing continuously lean trunk-based; teams shipping scheduled, versioned products may want more branch structure. The lesson isn't to memorize a winner; it's to recognize the options and understand that a team picks the workflow that fits how it actually ships.

With four people shipping small changes constantly, the Cadence team uses trunk-based development — short-lived branches merged into main daily, sometimes behind a feature flag — and keeps everything in a single repository, because nothing about their size yet justifies splitting it. As they'd be the first to say, that's the simplest thing that fits them today, and they'd reconsider only if they outgrew it.