ルールセットでレビューを却下できるユーザーを制限する機能 Restrict who can dismiss reviews in rulesets

GitHub has added the ability to restrict which users or teams can dismiss pull request reviews through rulesets, giving organizations more precise control over one of the more sensitive actions in the code review workflow. Dismissing a review effectively removes a prior approval or a "changes requested" verdict from the record, so governing who can perform that action matters for teams that treat review as a compliance or security gate rather than a courtesy.

In practice, a dismissed review no longer counts toward the approvals a pull request needs before it can merge, and it clears the outstanding objection a reviewer may have raised. In the past, that capability was generally available to anyone with sufficient write or administrative access to the repository, which meant an author or a colleague could, in principle, wave away a reviewer's blocking feedback. The new ruleset option lets administrators name the specific users, teams, or roles permitted to dismiss reviews, so the action is limited to a trusted subset instead of being implicitly granted to a broad group.

The feature lands within rulesets, GitHub's newer governance layer that overlaps with and increasingly supersedes classic branch protection rules. Rulesets were designed to be more flexible and scalable: they can be defined at the repository or organization level, can target multiple branches or tags using naming patterns, can be layered so that several rules apply at once, and expose an evaluation and enforcement model that is easier to audit. They also support an explicit bypass list, letting organizations define exactly who is exempt from a given rule. Branch protection has long included a comparable "restrict who can dismiss pull request reviews" setting, so this change appears aimed at bringing feature parity to rulesets and encouraging teams to consolidate their controls in one place.

For organizations, the practical benefit is stronger and more explicit governance over the review process. Code review is frequently one of the controls cited in internal policies, audit requirements, and software supply chain frameworks, where an approving review serves as evidence that a change was independently examined before shipping. If an approved or blocking review can be dismissed by too many people, that evidence becomes weaker and the control is easier to circumvent. Restricting dismissal to designated reviewers or a security team reduces the risk that a legitimate objection is quietly removed to unblock a merge, whether by mistake or intent.

It is worth distinguishing this control from adjacent review settings that rulesets already offer. Requiring a minimum number of approvals, requiring review from code owners, and dismissing stale approvals automatically when new commits are pushed all shape how reviews accumulate and expire. The new option instead governs the manual act of clearing a review that already exists. Used together, these rules let an organization describe a fairly complete review policy: how many approvals are needed, who must give them, when they reset, and now who is allowed to discard them.

The change fits a broader industry emphasis on tightening the controls around code before it reaches production. Concerns about supply chain integrity, reflected in frameworks such as SLSA and in various regulatory and internal audit expectations, have pushed platforms to make review and merge policies more granular and more auditable. Restricting review dismissal is a small but meaningful piece of that picture, because it closes a path by which an otherwise enforced review requirement could be neutralized.

Teams evaluating the feature should confirm how it interacts with existing branch protection rules, since running overlapping configurations across both systems can make the effective policy harder to reason about. Organizations that have not yet migrated from branch protection to rulesets may want to review where each control is defined and consolidate where it makes sense. As with other ruleset options, administrators can scope the restriction to specific repositories or apply it organization-wide, and the bypass mechanism remains available for cases where a defined set of actors needs to operate outside the rule. The capability is configured alongside GitHub's other pull request rules, so existing review policies can be extended without a separate workflow.