How to require code review on GitHub without grinding merges to a halt

If a pull request says “At least 1 approving review is required by reviewers with write access”, it needs an approval from someone with write access, and if the branch dismisses stale approvals, that approval has to be on the latest commit. The causes and fixes are below.

If review depends on everyone remembering to ask for it, it will be skipped exactly when it matters most. The fix is mechanical: require code review on GitHub with branch protection, so a pull request physically cannot merge without an approving read. The settings take five minutes; the policy design is the real work. This piece covers what the protections actually do, verified against the GitHub docs, and how to pick the configuration that guarantees a human read without turning every merge into a queue at the post office.

What it means to require code review on GitHub

The core setting is plain. Per the GitHub docs on protected branches, you can require that all pull requests receive a specific number of approving reviews before anyone merges them into the protected branch, and once required reviews are on, collaborators can only push changes to that branch through a pull request approved by the required number of reviewers with write access. That second half is the part teams forget: the rule does not just gate the merge button, it closes the direct-push side door. What the setting buys you is a guarantee that every change to main passed through a surface where review could happen. What it cannot buy you is the review itself, a gap we will come back to.

Stale dismissal, code owners, and the most recent reviewable push

Three companion settings decide whether the required approval means anything. First, “Dismiss stale pull request approvals when new commits are pushed.” With it on, GitHub dismisses approving reviews when new commits change the diff, so an approval describes the code that merges, not a version from last Tuesday. Without it, approve-then-rewrite is a one-person bypass. Turning it on is close to free on a team that keeps pull requests small, and expensive exactly where the expense is telling you something. Second, code owner reviews: any pull request that affects code with a code owner must be approved by that owner before merging, which is how you attach mandatory expertise to specific paths instead of raising the approval count everywhere; our CODEOWNERS guide covers keeping that file honest. Third, the quieter one: “Require approval of the most recent reviewable push.” Someone other than the person who pushed last has to approve that push, so a reviewer cannot push a last fix to a shared branch and then approve their own change.

“At least 1 approving review is required by reviewers with write access”

GitHub shows this message when required reviews are doing their job, and it tends to surprise someone who thought the pull request was already approved. Per the GitHub docs on required reviews, only approvals from people with write or admin access count, so an approval from a read-only collaborator or an outside contributor is ignored. The other common causes: stale dismissal removed the approval when a new commit landed, a reviewer with write access requested changes and has not approved since, or the most recent push came from the only person who approved. The fix is a fresh approval of the current commit from someone with write access, or dismissing a blocking review whose author is away. The same check appears as a repository rule violation when a ruleset, rather than a classic branch protection rule, requires the review.

“Waiting on 1 more approval because the last pusher could not be determined”

This one comes from the most recent reviewable push rule. GitHub needs to know who made the latest push so it can discount that person’s approval. When it cannot tie the push to a user, for example a push made by a bot or an app, it waits for one more approval from a reviewer with write access. The fix is that approval, given after the latest push.

“At least 1 reviewer besides most recent pusher must approve the most recent iteration”

This message is not from GitHub. It comes from Azure Repos, part of Azure DevOps, which calls each push an iteration. Its branch policies can require an approval on the latest iteration and stop the most recent pusher from approving their own changes, the same idea as GitHub’s most recent reviewable push rule. The fix is the same too: someone other than the last pusher approves after the latest push. A reviewer who approved before that push may need to reset their vote and approve again.

The bypass honesty problem

Here is the clause that decides whether your policy is real: by default, branch protection restrictions do not apply to repository admins or to roles granted the bypass permission. You can extend enforcement to administrators, and for most teams you should, but some bypass capacity usually survives for genuine emergencies. The problem is not that bypass exists; it is that bypass is quiet. A protection rule that senior people silently skip is worse than no rule, because everyone else can see the merged-without-review commits while the policy page still claims reviews are required. The workable norm is to treat every bypass as a public event: announced in the team channel when it happens, with a reason, and followed by a retroactive review. If that feels heavyweight, notice what that means: bypassing was becoming routine.

Design for the minimum friction that guarantees a read

The failure mode when configuring all this is symmetrical. Too loose, and the settings are decoration; too strict, and engineers spend their afternoons collecting approvals like signatures on a permission slip. The design principle we keep coming back to is the one from review by blast radius: match rigor to what breaks if the change is wrong. In branch protection terms, that usually means one required approval with stale dismissal as the repository-wide floor, and code owners layered on the paths where mistakes are expensive (auth, payments, data migrations, public API), effectively requiring a second, specific reviewer only where it pays. Blanket two-approval rules feel rigorous but mostly convert the second reviewer into a formality; Microsoft’s research on modern code review found the value of review lives in understanding and improvement, not in stacking sign-offs.

Protection is a floor, not a culture

Branch protection guarantees a click. It cannot guarantee that anyone read the diff, and a team that rubber-stamps will rubber-stamp straight through a required approval, one keystroke slower than before. The settings also age: paths gain new risk, code owners leave, and a configuration nobody revisits quietly drifts away from the risks it was meant to cover, so put a yearly review of the rules themselves on the calendar. None of that is an argument against the settings; floors matter, and the direct-push door should be closed on any codebase with users. It is an argument for keeping the two layers straight. The settings make skipping review impossible; only norms make review real, and those norms (approvals that say what was read, nits labeled, leaders who queue like everyone else) are built in the open, the way we describe in code review culture. Configure the floor in an afternoon. Expect the culture to take a year. Both are worth it, and neither substitutes for the other.