Working with Git as a Team: Branches, Reviews, and Staying Sane

Development & Code
, , , ,
1

Branch protection, collaboration workflows, resolving merge hell, and doing it without stepping on toes.

Disclaimer:
This guide is based on industry best practices and established documentation from platforms like GitHub, GitLab, and Atlassian. It is written to provide a safe starting point for teams learning to collaborate with Git.

While the workflows described have been minimally tested in controlled solo setups, I cannot accurately simulate or predict every aspect of real team dynamics, communication habits, or branching policies.

Use this guide as a reference, but always tailor it to your team’s needs and review changes in a staging environment before enforcing policies in production.

Working with Git solo is like riding a bike. Working with Git in a team? It’s a coordinated highway merge, and someone’s always signaling wrong. This guide will show you how to avoid disaster and actually enjoy team collaboration with Git.

1. Branching Strategies for Teams

A structured branch model keeps everyone in sync. Common setup:

  • main, production or stable branch
  • develop, integration branch for all upcoming changes
  • feature/*, bugfix/*, hotfix/*, short-lived working branches

Example:

git checkout -b feature/login-form

Tip: Always branch from main or develop, not another feature branch unless pair-programming.

2. Pull Request Etiquette

Pull Requests (PRs) are where collaboration happens.

Best practices:

  • Keep PRs small and focused
  • Use descriptive titles and summaries
  • Link related issues
  • Tag only relevant reviewers

Avoid:

  • Dumping a week’s worth of commits in one PR
  • Mixing unrelated changes

A good PR helps reviewers help you.

3. Protecting the Main Branch

You don’t want someone force-pushing to main on a Friday.

Enable protection rules:

  • Require PRs before merging
  • Enforce status checks (CI, Continuous Integration, must pass)
  • Restrict who can push
  • Optionally require multiple reviews

4. Handling Merge Conflicts Like Adults

Conflicts happen when two people touch the same code.

Avoid them by:

  • Pulling latest changes before starting
  • Communicating who’s editing what
  • Keeping branches short-lived

When it happens:

git pull --rebase
# or
git merge origin/main

Then resolve conflicts in your editor, mark as resolved, and commit.

5. CI/CD and Testing Before Merging

Teams rely on automated testing to avoid merging broken code.

CI/CD stands for Continuous Integration and Continuous Deployment (or Delivery).
It means every code change is automatically:

  • Built
  • Tested
  • (Sometimes) deployed

Modern platforms like GitHub Actions or GitLab CI let you:

  • Run lint checks, unit tests, and build pipelines automatically
  • Block merges until those checks pass

Don’t merge on red.

6. Communicate Through Commits

Keep your commit history clean and meaningful.

Good examples:

feat: add login validation
fix: resolve null crash on logout
docs: update README with auth flow

Consider:

  • Squashing commits before merging (git rebase -i)
  • Using merge commits when clarity is more important than a linear history

7. Safer Ways to Undo Mistakes

Do NOT use git reset on shared branches.

Instead:

git revert <commit>

Or:

git checkout -b fixup-branch
# make fixes, then PR

Also helpful: git reflog, git log, git blame

8. A Day in the Life of a Team Git Workflow

  1. Clone the repo
  2. Create a feature branch
  3. Code, commit regularly
  4. Push to remote
  5. Open a pull request
  6. Get a review
  7. Pass CI
  8. Merge or squash
  9. Pull main again

Need a Refresher on Git Commands?

If you’re unclear on what some of these Git commands actually do, like rebase, merge, or revert, check out
Git from the Command Line: The Real Way to Learn It
It’s a hands-on walkthrough of the most important commands, with examples.

Your Turn

Are you working in a team?
What’s your branching model? Your biggest mistake?
Share what’s worked (or what blew up), it helps everyone learn faster.