GitHub · Pull requests · Required reviews · Checked October 26, 2026

GitHub: the most recent push needs an approval from someone else

When a branch requires pull request reviews, its administrators can also require "approval of the most recent reviewable push": in a branch protection rule, or in the pull request rule of a ruleset. The most recent reviewable push must then be approved by someone other than the person who pushed it, which means at least one other authorized reviewer has approved any changes (GitHub's about protected branches and available rules for rulesets). Approvals given before that push stay on the pull request, so it can look approved and still be blocked (checked October 26, 2026).

GET /repos/OWNER/REPO/rules/branches/BRANCH        [{ "type": "pull_request", "parameters": { "require_last_push_approval": true, … } }]
GET /repos/OWNER/REPO/branches/BRANCH/protection   { "required_pull_request_reviews": { "require_last_push_approval": true, … } }
GET /repos/OWNER/REPO/pulls/N/reviews              [{ "state": "APPROVED", "commit_id": SHA, … }]

What the rule asks

Someone other than the pusher: the approval has to come after the most recent reviewable push, from someone other than the person who made it. GitHub's example is a "last reviewer" who checks that the latest changes take in the feedback from other reviews and add no new, unreviewed content.
Earlier approvals stay: with this option, "stale" reviews are not dismissed, and the pull request remains approved as long as someone other than the person who made the most recent changes approves it. A user who has already reviewed the pull request can approve again after the most recent push to meet the requirement.
Where it is set: in branch protection it is require_last_push_approval under required_pull_request_reviews ("whether the most recent push must be approved by someone other than the person who pushed it", false by default); in a ruleset it is the require_last_push_approval parameter of the pull_request rule. GraphQL calls it requireLastPushApproval. "Get rules for a branch" returns all active rules that apply to a branch, at whatever level they are configured; rules in rulesets that only evaluate, or are disabled, are not returned (GitHub's REST API endpoints for rules and for protected branches).

How it differs from dismissing stale approvals

Dismiss stale pull request approvals: GitHub records the state of the diff when a pull request is approved. If the diff changes (a contributor pushes new changes, someone clicks Update branch, or a related pull request is merged into the target branch), the approving review is dismissed as stale, and the pull request cannot be merged until someone approves the work again.
The most recent push: nothing is dismissed. GitHub describes it as a compromise for complex pull requests that need many reviews, and says that if you are concerned about approved pull requests being "hijacked" with unapproved content, it is safer to dismiss stale reviews.
With either setting: creating the merge commit yourself and pushing it to the protected branch fails unless its contents exactly match the merge GitHub generates for the pull request, and approving reviews are dismissed as stale if the merge base (the last common ancestor of the topic branch and the base branch) introduces new changes after the review: the pull request then cannot be merged until someone approves again.

Who can approve

Not the author: pull request authors cannot approve their own pull requests, and approvals by GitHub Copilot do not count toward the merge requirements (GitHub's approving a pull request with required reviews), though Copilot approvals, in public preview, count once they are turned on (see Copilot reviews). Under this rule, an approval from whoever pushed last does not meet it either.
A request for changes: under a rule that requires a pull request, a review requesting changes from a collaborator with admin, owner or write access keeps the pull request from merging until the same collaborator approves it. Administrators or people with write access can dismiss a review, with a comment saying why; it then becomes a review comment (GitHub's dismissing a pull request review).

What to do

Ask for an approval now: someone other than whoever pushed last approves the pull request as it is; a reviewer who approved before the push can simply approve again.
See which approvals are on the head: each review in "List reviews for a pull request" carries the commit_id it was made on; when a review is created through the API without one, it defaults to the most recent commit in the pull request (GitHub's REST API endpoints for pull request reviews). An approval made on an older commit was given before the head moved.
Push, then ask: an approval given before a later push no longer meets the rule, so ask for it once the branch is where you want to merge it.
Other review rules may hold it too: too few approvals, a code owner's review (see a code owner's review), or unresolved conversations (see the merge waits for conversations).

In IntelliJ IDEA: an approval is not tied to a push

How the GitHub support built into IntelliJ IDEA deals with approvals after a new push, in its source (checked October 31, 2026; IntelliJ IDEA: pullRequestReview.graphql, GHReviewersUtils.kt, GHPRReviewFlowViewModelImpl.kt, GraphQL files, GithubApiRequests.kt):

Not the rule: none of its 78 GraphQL files asks for requireLastPushApproval, and its list of REST requests has nothing for it.
Reviews without their commit: for each review it asks for the author, text, state and time, but not the commit the review was given on. Per reviewer it takes the latest approval or request for changes by time, so an approval given before the latest push still counts as an approval in the IDE unless GitHub has dismissed it. How it counts approvals: the merge waits for a team's approval.
Asking again: its code for re-requesting a review adds everyone who has reviewed, except the author, back to the review requests (how review requests are sent).

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 GitHub calls the pull request blocked, its merge checks name what they can read: required checks that have not reported, a review still required, unresolved conversations and unsigned commits the rules hold against it. Its reviewer list marks an approval given on an earlier commit, and when a blocked pull request has approvals and the branch's ruleset or protection requires approval of the most recent reviewable push, the merge checks say so and whether any approval is on the head commit; when the rules cannot be read and every approval was given on an earlier commit, they say it may be what holds the merge back. 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.