Collaborating with Git

This chapter follows Pull requests with and without GitHub.

Until now the series focused on your repository: commits, merges, and remotes. Collaboration starts when many people share one canonical history and need rules so pushes do not overwrite each other and reviews happen before production.

What Git does and does not enforce

Git enforces object integrity and ref updates on each clone. It does not enforce:

Code review before merge
Test passage
Branch naming
Who may push to main

Those rules live on the host (GitHub branch protection), in CODEOWNERS, and in team docs—CONTRIBUTING.md, runbooks, and chat norms. Treat undocumented expectations as bugs waiting to happen.

Shared remote as the contract

The remote (usually origin) is the contract point. Everyone **fetch**es the same commits; integration happens when maintainers accept merges to protected refs.

Typical flow:

Diagram 1

flowchart LR
  Dev[Developer clone]
  FB[Feature branch]
  PR[Pull request]
  Main[Protected main]
  Dev --> FB
  FB --> PR
  PR --> Main

Forks (open source) add a second remote—origin on your fork, upstream on the canonical repo. Sync upstream regularly so PRs stay small (Pull requests).

Roles: contributor and maintainer

Role	Typical permissions	Responsibility
Contributor	Read; push to non-protected branches or forks	Propose changes via PR or patch
Maintainer	Merge to protected branches; manage releases	Integrate, enforce policy, unblock CI

Small teams often give everyone maintainer access with mutual review. Larger teams narrow merge rights to reduce accidental production changes.

Agreements worth writing down

Document these before scaling headcount:

Default branch name and what it represents (production, integration, or both)
Branch naming (feat/, fix/, ticket ids)
Merge strategy (merge commit, squash, rebase and merge) and when each applies
Required checks before merge (lint, test, security scan)
Release tagging and who may create tags
Hotfix path when main must be patched under pressure

Link to Merging versus rebasing for history-shape decisions.

Async collaboration and conflict cost

Most collaboration is asynchronous: you push, someone reviews hours later, CI runs in between. That only works when:

Commits and PRs are small and scoped
main stays green or breaks are fixed quickly
Contributors rebase or merge latest main before review finishes

Long-lived branches without integration multiply conflict cost—the workflows in Git workflows for teams exist to manage that tradeoff.

Where to go next in this topic

Code review and pull request hygiene — review size, feedback, and commit messages reviewers actually use
Git workflows for teams — trunk-based development, Git Flow, GitHub Flow, and choosing a model

Next: Code review and pull request hygiene.