I've worked on teams with GitFlow so complex we needed a flowchart to make a hotfix. I've also worked on teams with no workflow at all—just everyone pushing to main and hoping for the best.
Both extremes suck. GitFlow is over-engineered for most teams. No workflow is chaos. There's a middle ground.
After years of testing different approaches, here's the Git workflow I recommend for most teams. It's simple enough to actually follow, robust enough to prevent disasters.
Why Your Git Workflow Matters
A good workflow prevents:
- Merge conflicts that take hours to resolve
- Broken main branches that block everyone
- Lost work from force pushes and rebases gone wrong
- Confusion about what's deployed where
A bad workflow creates friction. Developers spend more time managing Git than writing code. That's a tax on your entire team.
The Simple Workflow (That Works)
Here's the workflow. Three branch types, clear rules:
1. Main Branch: Always Deployable
Rules:
- Main is always deployable to production
- No direct commits to main
- All changes go through pull requests
- PRs require at least one review
- CI must pass before merging
Why: If main breaks, you can't deploy. This rule prevents that. Yes, it adds friction. That's the point. Friction prevents mistakes.
2. Feature Branches: One Feature, One Branch
Naming: feature/short-description or feat/ticket-123-description
Rules:
- One feature per branch (don't bundle unrelated changes)
- Branch off main, merge back to main
- Delete branch after merging
- Keep branches short-lived (days, not weeks)
Why: Long-lived branches diverge from main. Merging becomes painful. Small branches merge cleanly.
3. Hotfix Branches: Emergency Fixes Only
Naming: hotfix/short-description
Rules:
- Only for critical production bugs
- Branch off main, merge back to main
- Tag the release after merging
- Document what was fixed and why it was urgent
Why: Hotfixes bypass normal process. That's dangerous. Documentation ensures accountability.
Pull Request Process
The workflow is only half the battle. Your PR process matters just as much.
Keep PRs Small
Guideline: Under 400 lines changed. Over that, reviewers zone out. Bugs slip through.
If your PR is huge, split it. Multiple small PRs are better than one giant PR. Yes, it's more overhead. It's also more thorough.
Write Good PR Descriptions
Template I use:
## What
Brief description of what this changes
## Why
Business reason or problem being solved
## Testing
- [ ] Unit tests added/updated
- [ ] Manual testing done
- [ ] Screenshots (if UI changes)
## Checklist
- [ ] No console.log statements
- [ ] No TODO comments without ticketsMake it easy for reviewers. They shouldn't need to read your code to understand what you did.
Review Timing
Rule: PRs reviewed within 24 hours. Stale PRs block work. Set expectations.
We use a rotation: one person per week is "on call" for reviews. They know to prioritize it. Everyone else can focus on deep work.
Commit Messages That Do Not Suck
"Fixed stuff" is not a commit message. Future you will hate past you.
Good commit message structure:
Short summary (50 chars max)
Longer explanation if needed. What changed and why.
Not how—the code shows how. Why is what matters.
Wrap at 72 characters.Examples:
❌ Bad: "Fix bug"
✅ Good: "Fix null pointer in user authentication"
❌ Bad: "Update code"
✅ Good: "Refactor payment service for better testability"
❌ Bad: "WIP"
✅ Good: Don't commit WIP. Use a draft PR instead.Handling Merge Conflicts
Conflicts happen. Here's how to handle them without losing your mind:
- Rebase before merging:
git rebase mainon your feature branch. Resolve conflicts once, cleanly. - Communicate: If you're working on the same file as someone, talk to them. Coordinate changes.
- Smaller branches: Conflicts are proportional to branch age. Merge frequently.
Never: Force push to shared branches. You'll overwrite someone's work. They will hate you.
Tools That Make This Easier
Git is command-line by default. These tools make it better:
- GitHub Desktop: Visual Git for beginners. Surprisingly capable.
- GitKraken: Full-featured GUI. Great for visualizing branches.
- VS Code Git integration: Built-in, capable, convenient.
- GitLens: See who changed what and when. Invaluable for debugging.
Use whatever works. The best Git tool is the one you actually use.
What About GitFlow?
GitFlow has: master, develop, feature branches, release branches, hotfix branches. It's a lot.
When GitFlow makes sense:
- You maintain multiple released versions simultaneously
- You have dedicated release managers
- Your release process is complex and regulated
When GitFlow is overkill:
- You're a startup shipping continuously
- You have fewer than 20 developers
- You deploy multiple times per day
For most teams in 2026: continuous deployment + simple workflow beats GitFlow. Ship fast. Fix fast. Iterate.
Conclusion
Keep It Simple
Your Git workflow should enable your team, not constrain it. Start simple. Add complexity only when you have evidence you need it.
The workflow I described works for teams of 5 or 50. It's what I use on this site. It's what I've used at companies.
Try it. Adapt it. Make it yours. Just don't overthink it.
What's your team's Git workflow? Share on Twitter @mehitsfine.
Tags: