Key idea
main is the branch you deploy from, so a mistake there reaches users. A protected branch makes GitHub enforce the rules a team agrees on: changes arrive only through pull requests, someone else approves them, and the checks pass first.
Why protect main
Without protection, anyone who can push can put anything on main: an untested fix at midnight, a change nobody else has seen, or a force push that rewrites history others have built on. Each of these has taken real products down.
Protection turns "we always review" from a habit into a rule. It's there for the tired, rushed day, not the careful one.
The rules, as GitHub names them
A repository admin adds a branch protection rule for main in the repository's settings. The common ones:
- Require a pull request before merging. Nobody pushes to
maindirectly; every change goes through a pull request. - Require approvals. A set number of reviewers must approve. The author can't approve their own pull request, so at least one other person has read it.
- Require status checks to pass before merging. The checks you saw in the last lesson must be green.
Protected branches also block force pushes and deletion by default.
What a reviewer looks for
A reviewer reads the description, then the diff, and asks:
- Does it do what the description says, and nothing else?
- Could it break something: inputs it doesn't check, errors it swallows, a case the tests miss?
- Does it leak anything: a secret in the code, a value that belongs in configuration (modules 4 and 6)?
- Would I understand this in six months?
Then they submit one of three reviews: Comment, Approve or Request changes. Path 4 turns this into a full checklist in Read every diff, and works through a real example in Review an agent's pull request.
Good review comments
Name the line, the problem and a fix: "This logs the whole request, including the Authorization header. Log the path and status instead." A comment like that can be acted on straight away. "Looks good" on a change you didn't read is worse than no review, because it tells the team someone checked.
On your own pull requests, answer every comment, even with "Done". The reviewer then knows what changed without reading the diff again.
Working alone?
The rules still help. Requiring a pull request and passing checks stops you from pushing a broken commit straight to main on a bad day. Required approvals need a second person, so leave that one off until you have a reviewer.
Check yourself