Working with Git as a Team [Part 7 of 7]

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

---

---

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

---

2. Pull Request Etiquette

Pull Requests (PRs) are where collaboration happens. If you need a refresher, see Part 6.

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 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

For a full breakdown of these commands, see Part 4: Git from the Command Line.

---

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

---

Series Wrap-Up

That's the full Git series. Here's what we covered:

1. Setting up GitHub and your first repo
2. Managing repos with GitHub Desktop
3. Understanding branches
4. Git from the command line
5. Fork vs Clone
6. Pull requests
7. Team workflows (you're here)

Whether you're working solo or on a team, you now have the fundamentals to use Git without fear. Keep practicing, keep committing, and don't be afraid to break things. That's what branches are for.