A Git Workflow for Small Teams

Key Insights

• Keep main always deployable, use short-lived feature branches, and squash merge to maintain clean history
• One approval per PR is sufficient for small teams — more process adds friction without proportional quality gains
• Rebase on main before opening a PR to catch integration issues early and keep merges clean

Git Flow is overkill for small teams. GitHub Flow is almost right but skips some practical concerns. Here’s what actually works.

The Rules

1. main is always deployable
2. Feature branches come from main
3. Pull requests require one approval
4. Squash merge to keep history clean
5. Delete branches after merging

Branch Naming

feature/add-user-search
fix/order-total-calculation
chore/update-dependencies

The Daily Workflow

git checkout main
git pull
git checkout -b feature/my-thing

# Work, commit often
git add -A && git commit -m "Add search endpoint"
git add -A && git commit -m "Add search tests"

# Before PR, rebase on main
git fetch origin
git rebase origin/main

# Push and create PR
git push -u origin feature/my-thing

Commit Messages

Use conventional format but don’t overthink it:

Add user search by email
Fix order total including tax
Update Go to 1.22

Release Process

For most small teams, merging to main triggers deployment. If you need release gates, tag releases:

git tag v1.2.3
git push origin v1.2.3

The goal: minimize process while maintaining code quality. One approval, clean history, always-deployable main.