A Git Branching and Code Review Workflow That Scales Past Five Developers

Most teams blame branching strategy when they hit a wall around six developers. The thing that actually degrades with headcount is the quality and the latency of code review. Here is the workflow I install on every project, and the reason behind each piece.

Short-lived branches beat long-lived ones

A branch that lives three weeks carries three weeks of changes you have not seen and ends in a painful merge. It exists so you can work in parallel, then hand something reviewable to the next person.

• Open the branch the day you start and merge it within a day.
• If it will not merge quickly, the change is too big. Split it.
• Long-lived experiment branches only work if that code never ships in between.
• Delete branches on merge, or nobody can tell which work is real.

Trunk based versus feature branches, in practice

They are not opposites. Trunk based means main is always releasable, and short branches are perfectly fine inside that. You branch from main for a few hours, open a pull request, merge after review. Avoid the other extreme, where every developer keeps a personal branch for months. That model works until two people touch the same migration.

Commits that are atomic and reviewable

A commit is a unit of meaning, not a unit of time. One thing, tests passing on their own, revertable on their own. That property is what gives you bisect and clean reverts.

• Separate a refactor from a behaviour change.
• Write the message for whoever runs bisect six months from now.
• Why it changed matters more than what the diff already shows.
• Keep history short. Ten commits of a day's work is fine.

What a good review actually checks

Review exists for correctness and shared understanding, not formatting. A formatter in CI already owns indentation, import order and line length. Reviewers who spend their attention there leave the real problems untouched.

• Does it do what the ticket says, including the unwritten parts, and nothing else?
• What happens on empty input, very large input and concurrent requests?
• Do the tests cover behaviour, or do they just restate the implementation?
• Is anything sensitive in the diff, a token, a personal identifier, an unbounded query?
• Will a newcomer understand this in six months?

Comments should say what and why, never only what. A review full of restated lines is noise, and noisy reviews get skimmed.

Protecting main and automating the boring checks

The cheapest way to speed up review is to remove the questions a reviewer should never have to ask. Anything mechanical belongs in CI, because a human should not spend a review cycle on a missing newline.

• Require a pull request for main with at least one approval.
• Block direct pushes to main.
• Make format, lint, typecheck and tests required status checks.
• Keep the pipeline under ten minutes and parallelize as it grows.
• Merge with squash or rebase so main stays linear.

Key takeaways

• Branch for hours, not weeks, because review cost scales with diff size.
• Keep main always releasable and merge small branches into it daily.
• Write atomic commits with messages aimed at a future bisect.
• Review behaviour and risk, and let the formatter own style.
• Automate every mechanical check so reviewer attention goes to correctness.

FAQ

Q: Is trunk based development workable for a team that releases monthly?

A: Yes, and it fits monthly releases better than long-lived branches do. You merge to main daily and control what goes live with tags or feature flags, so main stays releasable while the release happens on your schedule. A monthly cycle is a release concern, not a branching concern.

Q: Our reviews are slow, should we require two approvals?

A: Not first. Slow reviews usually mean the diff is too large, the ticket is unclear or the author asked too late. Fix those and make sure mechanical checks run in CI so reviewers are not acting as linters. Only then is tightening rules for migrations and auth code sensible.