A minimum reviewer count only enforces review if you also control three settings: whether the author can approve their own change, whether the most recent pusher can approve, and whether new commits reset earlier approvals. Left at defaults, one person can add code and approve it.
The settings and what each one changes
Microsoft documents the following options on the "Require a minimum number of reviewers" policy.
| Setting | Effect | Why it matters |
|---|---|---|
| Allow requestors to approve their own changes | The author's vote counts toward the minimum | Off means the author's approval is ignored for the count |
| Prohibit the most recent pusher from approving their own changes | The last person to push cannot satisfy the count | Stops a second person who pushed commits from approving them |
| Reset all approval votes | Removes approvals when the source branch changes, keeps reject and wait votes | Approval covers the code that was reviewed |
| Reset all code reviewer votes | Removes every vote when the source branch changes | Strictest reset |
The documentation notes that by default anyone with push permission on the source branch can both add commits and vote on approval. That is the gap the pusher option closes. Microsoft frames it as segregation of duties.
Why vote resets are the quiet one
Imagine a reviewer approves a small change. The author then pushes a new commit that adds a dependency or changes a pipeline file. Without a reset, the earlier approval still counts. With a reset, the pull request needs a fresh look.
Pick the lighter reset if your team pushes many small review fixes, and the stricter one for sensitive repositories. The point is that approval should describe the code that will merge.
A baseline for sensitive branches
- Set a minimum of two reviewers on the default branch of repositories that deploy to production.
- Turn off author self approval.
- Turn on the prohibit most recent pusher option.
- Reset approval votes on any source branch change.
- Add automatically included reviewers for paths such as pipeline YAML and dependency manifests.
- Review who holds bypass permissions, because a bypass sits above all of this.
One more detail from the documentation: the self approval option exists on both the minimum reviewer policy and the automatically included reviewers policy, and each setting applies only to its own policy. If you change one, check the other.
Trade offs
Stricter settings cost time on small teams. A two person team that blocks pusher approval can deadlock when one person is away. In that case either keep the count at one with the pusher rule on, so the other person must review, or agree a documented fallback rather than loosening the policy for good.
Safeguard dependency scanning can add a technical check beside human review, so a reviewer is not the only thing standing between a risky package and your main branch. You can run a free scan at gold.safeguard.sh/scan.
Quick check
If the author cannot approve their own change, can they still vote?
Yes. The documentation says the creator can still vote Approve, but that vote does not count toward the minimum number of reviewers.
Does a new push remove existing approvals by default?
Not unless you enable a reset option. Choose a reset of approval votes or of all reviewer votes to make reviewers look again after the source branch changes.
Sources
Last reviewed: 19 October 2026.
