Branch protection is what stops the main branch from being damaged, even by mistake. You set a few rules and GitHub enforces them automatically: reviews required, tests must pass, direct pushes blocked. It's how teams protect their most important branch without having to watch it all the time.
About 2 min of reading
I had once merged a broken build straight to main by accident, and it was ugly to undo. Let me set the rules that stop main from being damaged even by mistake, require reviews, make tests pass before any merge, and block direct pushes so every change is forced through a pull request.
Start by checking what is already protecting main. A brand-new repo usually has no protection, so main can be pushed to directly by anyone. Seeing the current state before changing it is how you avoid protecting something that was already safe, or leaving something exposed.
Before you run it, say out loud what it will print. Then open the answer.
Turn on branch protection for main, and require at least one approval before any merge. With this on, no one can push bad code straight to main; the rules force review and testing before anything merges, no matter how many people work on the project.
Before you run it, say out loud what it will print. Then open the answer.
Require status checks to pass before the merge goes through. A status check is whether the pipeline passed, a build, lint, and test run. A red build can never reach main, which means everyone waits for the checks to turn green and the version that ships stays healthy.
Before you run it, say out loud what it will print. Then open the answer.
Block direct pushes so every change is forced through a pull request, and forbid force-push, which can wipe history. Restrict direct write to trusted maintainers; everyone else must open a PR. Even admins are not exempt, which stops an accidental force-push from destroying the timeline.
Before you run it, say out loud what it will print. Then open the answer.
Confirm the rules are actually in place. Protected status now means direct push is blocked, approvals are required, and tests must pass before anything merges. main can only change when the checks turn green, which keeps every version shippable.
Before you run it, say out loud what it will print. Then open the answer.
Protect main at minimum. Require reviews and passing tests, and block direct pushes so all work is forced through a PR. The branches that hold real data deserve the strongest rules.
Connect your CI to the protected branch. main can only merge when tests pass, which keeps every version shippable and gives everyone a clear signal that something's wrong.
Branch protection on main:
- Require 2 approvals
- Tests must pass
- No direct commitsWith these on, no one can push bad code straight to main. The rules force both review and testing before anything merges, which is exactly how a team keeps its flagship branch in a shippable state no matter how many people work on it.
Required status checks:
- CI (build + test)
- Lint
- Coverage reportA status check reports whether the pipeline passed, and you can block merges until it turns green. A red build can never reach main, which means everyone waits for the checks, and the version that ships stays healthy as a result.
Push restrictions:
- Direct push: maintainers only
- Everyone else: a PR is required
- No force-pushYou can restrict direct write access to trusted maintainers. Everyone else must go through a PR, so every change is reviewed. Even admins aren't exempt, which stops an accidental force-push from wiping history.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.