To require at least one approving pull request review before changes merge into main, create a branch protection rule or ruleset for that branch in your repository settings and turn on Require a pull request before merging with Require approvals set to 1. Save the rule, then open a small test pull request: GitHub should prevent a user without an approval from merging it. You need repository owner or administrator-level permission to configure this, and the exact menu labels can vary between personal repositories and organizations.
What this rule actually protects
A review request is a notification: it asks someone to look at a pull request. By itself, it does not stop a merge. A required-review rule is the enforcement step. When it applies to main, GitHub checks the pull request against that rule before allowing the merge method your repository supports.
That makes it a good baseline for a shared repository. One other person has a chance to spot an accidental file change, a missing test, or a confusing implementation before it becomes part of the default branch. It is not a promise that reviewed code is correct, secure, or ready to deploy. Treat the approval as one useful control alongside automated checks, tests, and a sensible release process.
For a solo repository, this rule may add friction without much value. For a project with more than one contributor, it usually creates a healthy pause before a consequential merge. Decide with the people who will be subject to the rule; do not quietly add it to a team repository and surprise everyone during an urgent fix.
Check the branch and your permissions first
Open the repository on GitHub and identify its default branch on the Code tab. It is often main, but an older project may use another name. The rule must target the branch that you want to protect, so copying a main example into a repository whose default branch is develop will not guard the branch people actually merge into.
You also need permission to manage repository rules. In many repositories, that means being the owner, an organization owner, or having admin access. If you cannot see Settings, or the branch/rules controls are locked, ask the repository owner rather than trying to change the workflow from a pull request. Organization policies and GitHub plans can affect which controls are available.
Before changing anything, tell collaborators what will happen: direct pushes may be restricted, and new pull requests may need an approval. A two-minute heads-up avoids the classic “Why can’t I merge?” interruption later.
Create a rule for the default branch
GitHub supports branch protection rules and repository rulesets. Either can enforce required pull-request reviews. The path you see depends on the repository and GitHub’s current interface:
- Go to the repository’s Settings.
- Open the branch protection or rules area. You may see Branches, Rules, or a prompt to create a ruleset.
- Create a new rule that targets the default branch—such as
main—rather than a broad pattern unless you intentionally want to cover several branches. - Enable the setting that requires a pull request before merging.
- Enable required approvals and set the number to
1. - Review the summary, save the rule, and note who is allowed to bypass it.
GitHub’s official protected branches documentation is the source of truth for the options and their current names. If your repository offers rulesets, GitHub’s ruleset documentation explains how their targeting and bypass lists work.
Keep the first rule narrow. Protecting main is easier to understand and test than applying a wildcard to every short-lived feature branch. You can expand the policy later after the team has used it successfully.
Choose stale approvals and bypasses deliberately
GitHub may offer a setting to dismiss stale approvals when new commits are pushed after approval. Turning it on means an approval no longer counts if the pull request changes afterward; a reviewer needs to look again. That is a strong fit when pull requests are small and review is part of the normal rhythm. It can be annoying when automated formatting or frequent rebases create harmless new commits, so discuss it before making it mandatory.
You may also see options concerning administrators, specific people, teams, or apps that can bypass the rule. A bypass is useful for a documented emergency process, but it weakens the everyday guarantee. Avoid treating it as the default shortcut for anyone who is impatient. If an emergency exception is needed, leave a clear pull-request note explaining why it was used and follow up with normal review afterward.
Do not confuse this review rule with a required status check. A pull request can have one approval while its tests are red. Once your test workflow is dependable, consider requiring it separately. Our guide to running Node.js tests on every GitHub pull request shows how to create that check before deciding whether to make it a merge requirement.
Test the rule with a harmless pull request
The rule is only useful if it applies the way you expect. Create a branch, make a harmless change such as a one-line README clarification, push it, and open a pull request into the protected branch. Do not approve it yourself if your policy is intended to require a second person; GitHub’s available review behaviors can depend on the rule and repository settings.
First, try to merge without an approval. GitHub should show that a required review is missing and keep the merge action unavailable or blocked. Then have an eligible collaborator approve the pull request. Confirm that the merge requirement clears only after that approval. If your team also uses checks, confirm their status remains visible and separate.
If the rule does not apply, recheck the target branch name, whether the rule was saved, and whether another, more specific ruleset takes precedence. Also look at any bypass list. Testing with a tiny pull request is much safer than discovering a misconfigured policy during a production change.
Keep reviews helpful, not ceremonial
One required approval works best when pull requests are reviewable. Keep each change focused, explain what changed and how you tested it, and answer comments before merging. A reviewer should be able to understand the intent without reconstructing a week of unrelated commits.
Automated scanning supplies a different signal from human review. It can flag certain risky patterns, but it cannot decide whether a change makes sense for your product. If you have not added it yet, see how to turn on GitHub code scanning for an existing repository. Keep both the review rule and the results you receive in proportion: neither is a box to check and forget.
Revisit the rule after a few weeks. If reviews routinely block small fixes because only one person has permission to approve, add an appropriate backup reviewer. If approvals are rushed, improve the pull-request template or shrink change size before increasing the required number. The goal is a reliable decision point before main, not a ritual that people learn to work around.
Official sources
- GitHub Docs: About protected branches
- GitHub Docs: About rulesets
- GitHub Docs: Approving a pull request with required reviews