Git Workflows for Solo Devs vs Teams of 5 vs Teams of 50
TL;DR: Scaling Git workflows is mostly about adding ceremony as your blast radius grows. Solo dev: just commit. Team of 5: PRs + main. Team of 50: protected branches + reviewers + release branches.
Solo dev
Commit straight to main. Push when you have a stopping point. Tag releases. The whole repo is your branch.
If you're working on something risky, branch — but for most solo work, branches add ceremony without payoff.
Team of 5
Feature branches + PRs to main. One reviewer required (or whoever's awake). Squash-merge so main reads as one commit per feature.
No release branches yet. Main is what's deployed. Hotfixes are commits to main.
# typical flow
git switch -c feat/billing-portal
# work, commit
git push -u origin feat/billing-portal
# open PR, get review, squash-merge to main
# CI deploys mainTeam of 50
Now you need: protected main, code-owners file, required CI checks, two reviewers, signed commits, release branches for stable cuts.
The shape of work changes too — features go behind flags, PRs target a develop or release-N branch, and 'merging to main' becomes a release event, not a daily one.
Where each workflow breaks
Solo dev with no branches dies the day you merge a half-finished refactor at 2am.
Team-of-5 dies when a feature takes longer than two weeks and the merge gets brutal.
Team-of-50 dies when ceremony exceeds throughput and PRs sit for days.
The cheat code: trunk-based development
All sizes can use trunk-based: short-lived branches, merge-or-rebase to main daily, ship behind feature flags. Google and Facebook use it at massive scale. Most teams who think they need GitFlow actually need feature flags + trunk-based.