Git Workflow That Actually Works for Small Teams

Most Git workflow advice was written for teams of 50+ or for open-source projects with external contributors. Small product teams have different constraints. Here's a workflow that's served teams of 2–10 well without the overhead of Git Flow and without the deployment confidence required for full trunk-based development.

The Simple Version

Main branch = production. Feature branches = your work. Short-lived (under a week). PR + review before merge. Delete branches after merge. That's 90% of the workflow. Everything else is refinement.

Commit Message Conventions

Conventional Commits (fix: title, feat: title, chore: title) are worth adopting even for small teams. They enable automatic changelog generation and make git log readable. The investment is one learning session and you get years of readable history. More importantly, 'fix: resolve null pointer in user auth' tells you more than 'fixed stuff' when you're debugging 6 months later.

Branch Naming

Simple naming reduces confusion: feat/short-description, fix/bug-description, chore/task-description. Some teams add ticket numbers (feat/FTK-123-user-auth). Whatever format you choose, apply it consistently. Random branch names ('johns-branch', 'test2', 'final-final') make cleanup and reference miserable.

The Squash Merge Debate

Squash merging combines all commits in a PR into one before merging. Pros: clean main branch history with one commit per feature. Cons: you lose the individual commit context from development. For small features, squash is fine. For large features where the commit history documents important decisions, regular merge preserves more information. Many teams default to squash for everything and accept the trade-off.

Protecting Main

Enable branch protection on main: require PR reviews, require status checks (CI passing), and prohibit force pushing. These three rules prevent the most common accidents: pushing directly to main, merging failing code, and rewriting shared history. Set these up on day one of a new project — it's harder to add them after bad habits form.