GitHub · Pull requests · Rulesets · Checked October 26, 2026

GitHub: the merge waits for a team's approval (Required reviewers)

The pull request rule of a ruleset can require review or approval from specific teams when a pull request changes certain files or directories: "Required reviewers". Each team has its own number of required approvals from its members and its own list of file patterns, so a pull request that touches those files stays blocked until enough members of that team approve it. For an approval from a team member to count, the team must have write permissions or higher for the repository (GitHub's available rules for rulesets, checked October 26, 2026).

"type": "pull_request",
"parameters": {
  "required_reviewers": [
    { "file_patterns": ["src/api/**"], "minimum_approvals": 2,
      "reviewer": { "id": 42, "type": "Team" } } ] }

How the rule works

Teams and approvals: a ruleset can name up to 15 teams, and for each team require from 0 to 10 approvals from its members. Requiring zero approvals adds the team to the pull request for visibility, but the team does not need to approve.
File patterns: each team has a list of file patterns that decides which files the setting applies to, in the same format as a .gitignore file. A pattern starting with an exclamation mark (!) is a negation, and patterns are matched in order, so a negated pattern can "unmatch" files that matched an earlier one.
Whose approval counts: approvals from members of the team, and only when the team has write permissions or higher for the repository.
Which teams can be chosen: for organization-wide rules, a team of the organization; for repository-level rules, a team of the organization that owns the repository. The rule is not available on user-owned repositories, as they do not contain teams.
Through the REST API: the rule is required_reviewers in the parameters of the pull_request rule, each with its file_patterns (fnmatch syntax), its minimum_approvals and its reviewer, a team given by its ID (GitHub's REST API endpoints for rules). "Get rules for a branch" returns the active rules that apply to a branch, whether they are configured on the repository or the organization; rules in rulesets that only evaluate, or are disabled, are not returned.

Next to the other review settings

The same pull request rule: Required reviewers sit in the pull request rule next to the required number of approving reviews, review from code owners, approval of the most recent reviewable push and conversation resolution, and each of those can hold the merge as well.
Team review assignment: when a team enables auto assignment, any time the team is requested to review a pull request, the team is removed as a reviewer and a subset of its members is assigned in its place, so the pull request may show those members instead of the team (GitHub's managing code review settings for your team).

What to do

Find the rule: anyone with read access to a repository can view its active rulesets (GitHub's about rulesets). In the pull request rule, the Required reviewers list the teams, their approvals and the file patterns; compare them with the files the pull request changes.
Ask the team: request a review from the team, or from its members, and wait for the number of approvals the rule asks.
Approvals that do not count: if members have approved and the merge still waits, check that the team has write permissions or higher for the repository; whoever manages the repository's access gives it to the team.
The team should not cover these files: whoever manages the ruleset narrows the team's file patterns (a negated pattern can leave files out), or sets its approvals to zero so the team is only added for visibility.

In IntelliJ IDEA: approvals are counted, not matched to the team

How the GitHub support built into IntelliJ IDEA deals with a rule that needs a team's approval, in its source (checked October 31, 2026; IntelliJ IDEA: pullRequestMergeability.graphql, refUpdateRule.graphql, GHPRMergeabilityStateBuilder.kt, GHPRReviewFlowViewModelImpl.kt, GraphQL files, GithubApiRequests.kt):

Not the rule: none of its 78 GraphQL files asks for requiredReviewers (the team, file patterns and minimum approvals of the pull request rule), for rulesets or for a team's members, and its list of REST requests has none for them either.
A number: for the base branch it reads one number, the required approving reviews. It keeps that number only while GitHub reports the merge as blocked, the account may push to the branch and every required check has succeeded (or none is required); otherwise it uses 0.
Its own review state: it counts the reviewers whose review is an approval. If that count reaches the number (with 0, a single approval), the state is accepted; otherwise the state follows GitHub's reviewDecision. It does not check whether an approval came from the required team.
Requesting the team: a team is requested by its slug (a team review request was replaced by team members).

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows a pull request's reviews, checks and conversations next to the diff, and merges it with the methods the target branch allows. When a pull request is blocked, its merge checks say when a review is still required and name the code owners asked to review, and when the branch's rulesets require approvals from teams for certain files, they name those teams with the approvals each needs and the files it covers (a team by its ID once it is no longer asked to review). The review inbox, diffs and conversations are free; approving, commenting, resolving and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.