For a small team, protect the main branch by requiring pull request reviews, requiring status checks to pass, blocking force pushes and deletions, and limiting who can bypass the rules. These four steps stop most accidental and unreviewed changes to your production code.
Why branch protection is the cheapest control
Your main branch is the source of what you ship. If anyone can push straight to it, a single stolen credential or a rushed late night commit can change production with no second pair of eyes. Branch protection is a setting, not a project, and it creates the review trail buyers ask about.
The settings, using GitHub's names
GitHub documents these settings for each branch protection rule: require pull request reviews before merging, require status checks before merging, require conversation resolution, require signed commits, require linear history, require merge queue, require deployments to succeed, lock branch, do not allow bypassing the settings, restrict who can push, allow force pushes, and allow deletions. Other code hosts offer similar controls under different names.
| Setting | Recommended for small teams | Why |
|---|---|---|
| Require pull request reviews | On, one approver | A second person sees every change |
| Require status checks | On, with tests and scans | Failing code does not merge |
| Require conversation resolution | On | Review comments cannot be skipped |
| Allow force pushes | Off | Keeps history trustworthy |
| Allow deletions | Off | Stops accidental loss of the branch |
| Do not allow bypassing | On, including admins | Rules apply to everyone |
| Require signed commits | Optional | Adds proof of author, with setup cost |
Two caveats worth knowing
GitHub notes that only one branch protection rule applies at a time, which can make it hard to know which rule is in force when several match a branch. Rulesets do not have that restriction. If you have several rules, check which one actually applies.
Also, with two or three engineers, requiring one approval can block urgent fixes when a person is away. Name a backup reviewer for each repository, and keep the bypass list short and logged rather than empty.
Add a security check to the status list
The most useful required status check is an automated scan on the pull request, such as dependency and static code checks. Required checks turn "please remember to scan" into something that cannot be skipped. Keep them fast, since slow checks get bypassed.
Test that it works
Once a quarter, try to push directly to main with a normal account. It should be refused. Record the date. Add the check to your quarterly review.
Common mistakes
Protecting only the main branch and forgetting release branches. Letting administrators bypass rules by habit. Requiring approvals from people who do not read the diff. Making checks so slow that people look for workarounds.
Where Safeguard fits
Safeguard offers policies, gates and guardrails for pull requests and dependency scanning. It also provides SBOM and dependency scanning, reachability analysis to show which findings are actually exposed, and policies and gates for pull requests. A free scan is at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Open the pull request and watch what happens when a check fails, which is what a required status check enforces.
Quick check
Do we need signed commits?
Not at first. Pull request review and required checks give more protection for less effort.
Do these rules apply to admins?
They should. Use the option that prevents bypassing, and keep any exception list short and logged.
Sources
Last reviewed: 19 October 2026.
