Code Review & Protected Branches
Pull/Merge Requests as a Quality Gate
On real teams, main is usually protected at the hosting-platform level (GitHub/GitLab) - the platform itself refuses direct pushes to it, no matter who you are. Every change must go through a Pull Request (GitHub) / Merge Request (GitLab) instead, the flow you first saw in the Remotes module.
| Control | What it does |
|---|---|
| Branch protection | Blocks direct pushes to main; requires PRs for every change |
| Required reviews | Demands N human approvals before a PR can merge |
| Required status checks | CI/tests must pass (turn green) before merge is even allowed |
| CODEOWNERS | Automatically requests review from the right people, based on which files changed |
| Linear history | Requires squash or rebase merges only, keeping main's history free of tangled merge commits |
Goal: Understand why this exists: main ships to production. Human review catches design and logic problems a computer can't; automated tests catch regressions before customers do. Together they turn every change into an auditable, defensible decision, and PRs create a permanent, searchable record of why every change was made - invaluable months later when someone asks "why is this line here?"
Good review etiquette: keep PRs small enough to actually review carefully, write a clear description of what and why, respond to every comment (even just "done" or "good point, fixed"), and never merge your own PR without the required approvals, even if you're confident it's fine.
Tip: Squash-merge turns a messy 12-commit branch ("wip", "fix typo", "actually fix", "forgot a file") into one clean, readable commit on main. Great for keeping the main-line history tidy, at the cost of losing the individual small commits from the branch (they still exist in the closed PR on GitHub/GitLab if you ever need to dig them up).