How do you require pull request approvals with GitHub branch protection?

You require pull request approvals by enabling branch protection for the target branch and turning on required reviews before merge. Set the number of required approvals, decide whether code owners must approve, and block bypass through direct pushes or force pushes where possible. Monitor for administrative overrides, because protection only works if exceptions are tightly controlled.

What branch protection is doing when you require PR approvals

Pull request approvals are a merge gate, not just a review habit. branch protection makes the target branch enforce that gate, so changes cannot land until the required review condition is satisfied. In practice, this shifts trust from the individual committer to the repository policy, which is important when multiple people can contribute to the same codebase.

That control only works if the protected branch is truly the merge path for the repository. If contributors can still push directly, rewrite history, or merge through an alternate route, the approval requirement becomes advisory instead of enforceable. For teams managing GitHub-based delivery, this is the same policy concept documented in GitHub and GitHub Actions Security Guide.

Approval rules also need to reflect the kind of change being made. Requiring one approval is often enough for low-risk repositories, but higher-risk codebases usually need code owner review, stronger review quorum, or both. The practical point is to align approval depth with the blast radius of a bad merge, not with the convenience of the development team.

How to set approvals so they actually hold up

In GitHub, the usual pattern is to enable branch protection on the target branch, then require pull request reviews before merge. From there, set the required approval count, decide whether code owners must approve, and make sure the rule applies to the branch pattern you actually use for releases or production changes. The goal is to make the default path safe without depending on individual discipline.

Approval settings are more reliable when paired with controls that narrow bypass routes. If administrators can bypass protections freely, the rule still exists, but it no longer provides strong assurance. That is why mature repositories treat administrative override as an exception path that must be monitored and justified rather than as a routine convenience.

For teams that want a broader operational view of GitHub hardening, GitHub and GitHub Actions Security Guide is useful because it places branch protection alongside codeowners, workflow hardening, and other repository controls that shape the real merge path.

What usually breaks the approval model in practice

The most common failure is treating approvals as a checkbox while leaving other merge paths open. Direct pushes, force pushes, and unconstrained admin bypasses can all defeat the intent of branch protection if they are allowed too broadly. A second failure is weak review quality, where approvals are collected but the reviewer does not meaningfully inspect the change.

Another practical issue is that approval rules can be undermined by automation and repository workflows. If bots, service accounts, or workflow changes can alter the protected branch path without equivalent review, the repository can still move faster than the control model was designed to permit. That is why approval policy should be reviewed together with the way automation writes to the repository.

When repository changes themselves become the attack path, incident history matters. The SpotBugs token leak 2025 illustrates how a compromised token and a weak workflow boundary can turn repository access into a supply-chain event, even when the change process looks normal on the surface.

Risk and Threat Considerations

Branch protection reduces the chance of an unsafe merge, but it does not eliminate repository compromise. The main risks are bypass abuse, weak review discipline, and stolen credentials or tokens that can alter protected branches through an allowed path. If those conditions exist, the approval rule may give a false sense of control.

Failure mechanism: An attacker or insider uses a direct push, force push, admin override, or stolen token to land code without meaningful review, or to manipulate the repository state so the approval requirement no longer protects the intended branch.

Impact: Malicious or unsafe code can reach production, auditability can be weakened, and downstream delivery systems may trust a compromised repository state as though it were reviewed and approved.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-5 — Account Management	GitHub branch protection depends on tightly governed merge and override accounts.
Recommendation — Restrict repository override privileges and review all accounts that can bypass branch protections.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Approval bypass and merge rights should be limited to the minimum needed roles.
	AU-12 — Audit Record Generation	Administrative overrides and branch policy changes need traceable logs.
Recommendation — Limit who can bypass protections or merge directly to protected branches. Log branch protection changes, bypasses, and merge exceptions for review.
ISO/IEC 27001:2022	A.8.9 — Configuration management	Branch protection is a repository configuration that must be controlled and reviewed.
Recommendation — Manage branch protection as controlled configuration and review changes formally.

Practitioner Guidance

What to verify: Confirm the protection rule applies to the exact branch used for release, that required reviews are enforced before merge, and that bypass options are limited to a small set of accountable users.

What to measure: Track how often branch protection is overridden, how often merges are approved by code owners versus general reviewers, and whether direct write paths still exist for protected branches.

Common mistake: Assuming approvals are effective because the setting is enabled, when the repository still allows an alternate merge path or a broad administrative bypass.

Practitioner takeaway: Treat pull request approvals as an enforcement control, not a process preference, and validate the merge path end to end so no unreviewed route remains open.