Git workflows that actually scale with your team
·2 min read ·DevOps · Git · Best Practices
There's no universally correct Git workflow. The right answer depends on how many people are on your team, how often you deploy, and how stable your releases need to be. Here's how I think about it.
Trunk-Based Development
Everyone commits to main (or a short-lived branch that merges within a day). Feature flags gate incomplete work. Continuous deployment ships to production on every green commit.
This works well when:
- Your team is small (2-5 people)
- You have good test coverage and CI
- You can deploy multiple times per day
The advantage is minimal merge conflicts and constant integration. The discipline required is high—you can't let broken code sit in main.
Feature Branch Workflow
Developers work on branches, open PRs, get review, merge. More familiar, more compatible with async review cycles.
git checkout -b feature/user-authentication
# work, commit, push
git push origin feature/user-authentication
# open PR, get reviewed, merge
The PR Size Problem
The biggest failure mode of feature branches is big PRs. A 2,000-line PR doesn't get reviewed—it gets approved. Break work into small, independently mergeable pieces. If a feature requires five separate logical changes, open five PRs.
A PR should represent a single idea, not a sprint's worth of work.
Conventional Commits
feat: add user authentication
fix: resolve order total rounding error
chore: update PHP to 8.4
Consistent commit messages let you auto-generate changelogs, understand history at a glance, and determine semver bumps automatically. Small investment, large return.
My Default
For most teams: feature branches with short lifetimes (merge within 2-3 days), conventional commits, and CI that blocks merges on failing tests. Simple, understood, scales to about 15 engineers before you need to think harder.