A Clean Git Branching Strategy for Teams

Your branching model is your team's safety net. The best ones are boring: a protected main, short-lived feature branches, and pull requests that are small enough to actually review.

The workflow

1. Branch off main for every change.
2. Commit small, with messages that say why.
3. Open a pull request early — even as a draft.
4. Squash-merge back to main.

Start a change

git checkout main
git pull --rebase
git checkout -b feat/invoice-pdf

Commit messages that age well

# conventional style: type(scope): summary
git commit -m "feat(invoicing): render PDF on export"
git commit -m "fix(api): clamp page size to 500"
git commit -m "refactor(db): extract quote builder"

Write the why in the body, not the title. Six months later, "why did we do this" is the only question that matters.

Keep your branch fresh

# replay your work on top of latest main
git pull --rebase origin main

# if a conflict:
git add <resolved-file>
git rebase --continue

Ship it

git push -u origin feat/invoice-pdf
# open the PR, get review, then squash-merge
# afterwards, clean up:
git checkout main && git pull
git branch -d feat/invoice-pdf

Protect main in your host (require PRs, passing CI, at least one review). The ceremony is small; the payoff is a history you can actually read and a branch you can always deploy.