Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To require code review before changes reach a GitHub branch, protect that branch, require pull requests, and set a minimum number of approvals. These are separate controls: requiring a pull request alone does not necessarily require anyone to approve it.
Set up required reviews with branch protection
- Choose the branch to protect. In the repository, open Settings → Branches and add a branch protection rule. Enter the exact branch name or a pattern that matches the branch receiving changes, such as your main development branch. Check that the pattern covers the intended branch without protecting unintended branches. GitHub’s branch protection guide explains rule configuration.
- Require a pull request before merging. Enable the pull-request requirement. This prevents changes from being merged through the normal workflow without a pull request, but it does not by itself establish an approval requirement.
- Set the required approval count. Enable required approving reviews and choose the minimum number. GitHub describes eligible approvals as coming from people with write permission. Set the number according to your team’s size and the risk of changes; no single count suits every repository. See GitHub’s documentation on available rules for how review requirements are described across rules.
- Choose what happens when code changes after approval. Select stale-approval dismissal, approval of the most recent reviewable push by someone other than its author, or neither, based on the review process you want. The tradeoffs are explained below.
- Save the rule and verify its effect. Use a pull request targeting the protected branch to check that GitHub displays the expected merge requirements and blocks merging until they are met.
Choose how later changes affect approval
Dismiss stale approvals
Enable this when an approval should no longer count after relevant changes are made. GitHub can dismiss an earlier approval when changes affect the pull request’s diff; a changed merge base can also make an approval stale. This is a stricter option, but a new approval may be needed after updates that require another review.
Require approval of the latest reviewable push
Alternatively, require an approval of the most recent reviewable push from someone other than the person who made that push. This focuses the additional approval requirement on the latest push rather than dismissing every prior approval. It is useful when the team wants another person to check the latest changes while retaining earlier approvals where applicable.
GitHub warns that either stale-approval dismissal or latest-push approval affects direct manual merge-commit pushes to a protected branch: the push fails unless the merge exactly matches GitHub’s generated merge. Review the implications if your workflow relies on such pushes. Details are in the ruleset rule documentation.
#1 Best Overall
Require code owner review for specific files
For path-specific review, add a CODEOWNERS file to the relevant branch and enable the code owner review requirement in the protection policy. GitHub looks for this file in .github/, the repository root, or docs/. The file must cover the paths that need designated reviewers. If multiple owners match a file, approval from any one of them satisfies that code owner requirement. See GitHub’s code owner documentation.
Protect the policy itself: GitHub recommends assigning an owner to the CODEOWNERS file or the .github/ directory so changes to review ownership receive appropriate oversight.
Branch protection rules or rulesets?
Classic branch protection rules are configured in repository Settings → Branches. Rulesets are another way to define repository rules. GitHub says rulesets can be easier to discover without admin access and can apply multiple rulesets at once; the available rules and behavior differ. If your team already uses rulesets, check the current ruleset documentation to confirm the review controls and how they combine with existing policies.
What review approval does—and does not—enforce
Required reviews are one merge gate, not a complete branch policy. Configure other protections separately if your team needs them, including required status checks, conversation resolution, signed commits, linear history, a merge queue, deployment requirements, push restrictions, or bypass rules. Their availability depends on the repository’s configuration and plan. GitHub’s protected branches documentation describes these controls and plan availability. Verify the current plan details for your account before relying on a specific feature.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
