Git Workflow for Small Teams
When you read about git workflows, most articles describe enterprise setups with release branches, hotfix branches, and complicated merge strategies. That's overkill for a team of three developers shipping a SaaS product.
Small teams need something simpler. Here's a workflow that gives you the benefits of structured development without the overhead.
The Basic Flow
Keep it simple: one main branch that's always deployable, short-lived feature branches, and pull requests for review.
That's it. No develop branch. No release branches unless you actually need them. Most small teams don't.
The workflow looks like this:
- Pull latest main
- Create a feature branch
- Make your changes
- Open a pull request
- Get review and merge
- Delete the branch
Simple enough that everyone follows it consistently. Complex enough to prevent chaos.
Branch Naming Conventions
Consistent branch names make everything easier. Pick a convention and stick with it. Something like:
feature/add-user-searchfor new featuresfix/login-timeout-bugfor bug fixeschore/update-dependenciesfor maintenance
Including a ticket number helps too: feature/PROJ-123-add-user-search. Now you can always trace a branch back to its ticket.
The specific format matters less than consistency. If everyone uses different patterns, your branch list becomes chaos.
Keep Branches Short-Lived
Feature branches should live for hours or days, not weeks. Long-lived branches cause painful merges and hide work from the team.
If a feature takes two weeks to build, break it into smaller pieces that can merge incrementally. Use feature flags to hide incomplete work from users while still merging to main.
The longer a branch lives, the more it diverges from main, and the harder the eventual merge becomes. Short branches mean small, easy merges.
Pull Requests for Everything
Even on a small team, pull requests are worth it. They provide:
- A chance for someone else to catch mistakes
- Knowledge sharing about what's changing
- A record of why changes were made
- A natural point for CI to run
Reviews don't need to be formal. A quick look from a teammate is enough. The goal isn't bureaucracy. It's catching obvious mistakes and keeping everyone informed.
Merge Strategy: Squash or Not?
You have three options when merging: merge commits, squash merging, or rebasing.
Merge commits preserve all the individual commits from the branch. Good if those commits tell a story, messy if they're full of "WIP" and "fix typo."
Squash merging combines all commits into one. Main stays clean with one commit per feature. You lose the detailed history but gain clarity.
Rebasing replays your commits on top of main. Keeps history linear but can cause problems if others are working off your branch.
For most small teams, I recommend squash merging. It keeps main readable without requiring developers to maintain perfect commit hygiene during development.
Commit Messages Matter
Whether you squash or not, good commit messages are valuable. When something breaks, you'll be reading git history to understand what changed.
The format that works well:
Short summary under 50 characters
Blank line
Longer explanation if needed. What changed and why. Include ticket numbers.
The summary should complete the sentence "This commit will..." So "Add user search endpoint" instead of "Added user search endpoint" or "user search."
Handling Conflicts
Merge conflicts are inevitable when multiple people work on the same codebase. The key is catching them early.
Before opening a PR, pull the latest main and merge or rebase to resolve conflicts locally. Don't make reviewers deal with conflict resolution.
When conflicts happen, communicate. If you and a teammate keep conflicting in the same file, coordinate your work to avoid stepping on each other.
When You Actually Need Release Branches
Some teams do need more structure. If you're shipping versioned software (mobile apps, on-premise installations), you might need release branches to maintain multiple versions.
But if you're shipping a web app with continuous deployment, you probably don't. Main is your release branch. Every merge to main can go to production.
Add complexity only when you feel the pain of not having it. Most small teams adopt enterprise workflows too early and create unnecessary overhead.
Protect Main
Set up branch protection rules so nobody can push directly to main. All changes should go through pull requests.
Also require CI to pass before merging. A broken main branch stops everyone. Preventing broken code from merging is easier than fixing it after the fact.
Automate What You Can
Set up CI to run tests on every PR. Configure automatic deployment when main changes. Use bots to remind reviewers about stale PRs.
The less manual work required, the more consistently people follow the process. Automation turns best practices into defaults.
Document Your Workflow
Write down your workflow in your repo's README or a CONTRIBUTING file. When new people join, they should be able to understand how to contribute without asking a bunch of questions.
Include your branch naming convention, merge strategy, and any team-specific rules. A simple workflow only works if everyone follows it the same way.