The Branching Strategy That Fits a Team of Two Will Break a Team of Ten

How the Workflow Gets Stuck

You hired four new engineers last quarter. The team doubled. Delivery hasn't doubled — if anything, it's gotten slower. PRs sit longer. Main breaks more often. Conflicts are larger and take longer to resolve. Someone suggests "we need a better process," and the team spends a week debating Gitflow vs. trunk-based development while the backlog grows.

The branching strategy you were using worked at two people because you had implicit coordination — two developers know what each other is doing. At eight people, that implicit knowledge is gone, and the workflow that relied on it breaks.

What Changes at Different Team Sizes

Two to three developers

The implicit model: everyone knows what everyone is working on. Branches are short because things move fast. Review is often synchronous. Merge conflicts are rare because there's minimal overlap. Direct commits to main are low risk because trust is high and the bus factor is manageable.

A simple "branch per feature, merge to main after quick review" workflow is sufficient. No enforced naming conventions. No required CI gates (though you should have them). The overhead of formal process exceeds its value.

Four to eight developers

Implicit coordination starts failing. Three people can't keep mental track of six other people's active work. Branches start living longer because review queues develop. Conflicts get larger because multiple people are touching overlapping areas.

What you need here:

• Branch naming conventions that indicate ownership and ticket linkage (feature/ENG-123-short-desc)
• Required CI on every PR before merge
• A clear rule about minimum reviewer count (one is usually sufficient at this size)
• Auto-delete branches after merge
• A rule about maximum branch age (if a branch is more than a week old, it needs attention)

Eight to twenty developers

This is where ad-hoc processes collapse. The PR queue becomes a real bottleneck. Developers are regularly waiting days for reviews. Main breaks often enough that the team starts treating it as normal. Someone proposes a "develop" integration branch to isolate instability, which immediately becomes a second problem rather than a solution.

What you need:

• Code ownership (CODEOWNERS files) to route PRs to the right reviewers automatically rather than waiting for someone to self-assign
• Merge queues to handle concurrent PR merges that would otherwise break main serially
• Feature flags to decouple feature completeness from branch mergeability
• WIP limits — a norm that each developer has at most two active PRs in review at any time, to prevent the queue from becoming unmanageable
• Automated stale branch cleanup

Twenty or more developers

At this scale, you likely have multiple teams, and the coordination problem is now inter-team, not just intra-team. A single main branch with multiple active teams requires explicit ownership boundaries. Teams working on different services with a shared platform layer will conflict constantly without clear API contracts and component ownership.

The branching strategy becomes less important than the architectural boundaries. Microservices with separate repositories sidestep much of the coordination problem. Monorepos require path-based CI triggers (only rebuild and test the affected components) and strong CODEOWNERS enforcement.

The Signs Your Strategy Has Outgrown Your Team Size

Merge conflicts are a weekly occurrence on the same files. Multiple people are touching the same files without coordination. You need ownership boundaries and smaller, more frequent integrations.

PRs sit for more than two days on average. Review throughput isn't keeping up with PR volume. Either reduce PR size, add reviewers, or reduce the overhead of the review process (required approvals from specific individuals are a common culprit).

Main is broken more than 5% of the time. CI is failing on trunk regularly. Either your CI gates aren't blocking enough, or developers are merging before CI completes. Both are fixable with tooling: required status checks and merge queues.

Nobody knows what's actively being developed. The branch list is unreadable. You need naming conventions and a norm of keeping the branch list current.

Integration surprises at merge time are common. Two branches both changed the same system behavior without knowing about each other. You need shorter branch lifetimes, more communication about who's working on what, and possibly architectural ownership boundaries.

Evolving the Strategy Without a Rewrite

The mistake teams make is treating "change the branching strategy" as a project requiring a team alignment meeting, a two-week transition plan, and documented new processes. It's actually a series of small changes:

1. Turn on auto-delete merged branches today. Takes two minutes.
2. Add a CODEOWNERS file to route reviews automatically. Takes an hour.
3. Enable required status checks for CI on main. Takes thirty minutes.
4. Set a team norm that PRs over 400 lines need to be split. Needs one conversation.
5. Enforce branch naming via commit-msg or PR title checks. Takes an afternoon.

Each of these changes is independent and reversible. You don't need consensus on the grand strategy — you need incremental improvements that reduce the friction that's actually causing pain right now.

The branching strategy that served you at three people isn't wrong. It was right for three people. When you have ten, it needs to evolve to match the coordination needs of a larger group. The failure is not changing it when it stops working.