In month one, every software company should protect production branches, require pull request review and passing checks, limit who can bypass those rules, and apply the same settings to every new repository by default. These settings cost little, take days not months, and underpin every later control.
Why start with repositories
For a software company, the source host is the front door to production. A change merged to main usually becomes a release. If anyone can push straight to main, or an admin can bypass review without a trace, scanning and gates later in the pipeline protect less than they appear to.
The settings, one by one
GitHub's documentation on protected branches lists the settings available in a branch protection rule, including requiring pull request reviews before merging, requiring status checks, requiring conversation resolution, requiring signed commits, requiring linear history, requiring a merge queue, requiring deployments to succeed, locking the branch, restricting who can push, and controlling force pushes and deletions. Other source hosts have equivalents.
| Setting | Why it helps | Start here? |
|---|---|---|
| Require pull request review | A second pair of eyes before changes reach main | Yes |
| Require status checks | Tests and scanners run before merge | Yes, once checks are stable |
| Block force pushes and deletions | Protects history | Yes, it is the default in a rule |
| Do not allow bypassing | Applies to admins too | Yes, with a documented emergency path |
| Require signed commits | Ties commits to identities | Later, once tooling is ready |
| Merge queue | Keeps main green under load | When team size makes it useful |
Watch the bypass lists
GitHub notes that by default, a branch protection rule's restrictions do not apply to people with admin permissions, and that bypass lists can be set when a repository belongs to an organization. If admins can skip review quietly, the rule is advisory. Decide who can bypass, keep that list short, and log use. Define an emergency path that leaves a record, such as a post merge review within a day.
Apply it everywhere, not one repo at a time
GitHub also notes that a single branch protection rule applies at a time, which can make overlapping rules confusing, and that rulesets avoid this restriction. For a growing company, rulesets or an equivalent organization level default are worth a look, because a new repository then starts protected instead of waiting for a person to remember.
A month one checklist
- List repositories and mark the production ones.
- Turn on protection for the main branch of each.
- Require at least one reviewer and the checks you already trust.
- Review the admin and bypass lists.
- Set an organization level default for new repositories.
- Record the settings in your handbook.
Try it yourself
This demo shows a pull request gate. Click through it and look at how required checks and review combine to decide whether a merge can proceed.
Click through it at your own pace, or open it full screen.
Safeguard's policies, gates and guardrails add security checks to that merge path. The free scan lets you try one repository first.
Quick check
Is one required reviewer enough?
It is a sound start for a first year baseline. Raise it for sensitive code paths when your team size and risk justify it.
Should admins be exempt from the rules?
Avoid exemptions by default. If you keep an emergency bypass, restrict it, log it and review each use.
Sources
Last reviewed: 19 October 2026.
