GitHub・プルリク・必須のレビュー・2026年10月26日に確認

GitHub：最後の push に、ほかの人の承認が要る

プルリクのレビューを必須にしたブランチでは、管理者がさらに「最後の reviewable な push の承認」（Require approval of the most recent reviewable push）を求められます。ブランチの保護でも、ルールセットのプルリクの規則でも設定できます。そうすると、最後の push は、push した人以外が承認する必要があります。つまり、どの変更にも、ほかの権限のあるレビュアーの承認が少なくとも1つ付いているということです（GitHub の説明「保護されたブランチについて」と「ルールセットで使える規則」）。その push より前の承認はプルリクに残るので、承認済みに見えても止まることがあります（2026年10月26日に確認）。

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, … }]

ルールが求めること

push した人以外：承認は、最後の reviewable な push の後に、その push をした人以外から必要です。GitHub の例は「最後のレビュアー」で、最新の変更がほかのレビューの指摘を取り込み、まだレビューされていない内容を足していないかを確かめます。
前の承認は残る：この設定では「古い」レビューは取り消されず、最新の変更をした人以外が承認している限り、プルリクは承認された状態のままです。すでにレビューした人も、最後の push の後にもう一度承認すれば、この条件を満たせます。
設定の場所：ブランチの保護では required_pull_request_reviews の require_last_push_approval（「最後の push を、push した人以外が承認する必要があるか」・既定は false）、ルールセットでは規則 pull_request のパラメータ require_last_push_approval です。GraphQL では requireLastPushApproval です。「Get rules for a branch」は、ブランチに当てはまる有効な規則を、どの階層で設定されたものでも全部返します。評価だけのルールセットや無効のルールセットの規則は返しません（GitHub の説明「ルールの REST API」と「保護されたブランチの REST API」）。

古い承認を取り消す設定との違い

Dismiss stale pull request approvals：GitHub は、承認された時点の差分を記録します。差分が変わると（新しい変更が push された・だれかが Update branch を押した・関係するプルリクが対象のブランチにマージされた）、承認のレビューは古いものとして取り消され、だれかがもう一度承認するまでマージできません。
最後の push の承認：何も取り消されません。GitHub は、多くのレビューが要る複雑なプルリク向けの折衷案だと説明し、承認済みのプルリクに承認されていない内容を足される（「乗っ取られる」）のが心配なら、古いレビューを取り消すほうが安全だと書いています。
どちらの設定でも：マージコミットを自分で作って保護されたブランチへ push すると、GitHub がそのプルリクに作るマージと中身が完全に同じでない限り失敗します。また、レビューの後にマージベース（トピックブランチとベースブランチの最後の共通の祖先）が新しい変更を持ち込むと、承認のレビューは古いものとして取り消され、もう一度承認されるまでマージできません。

だれが承認できるか

作者は承認できない：プルリクの作者は自分のプルリクを承認できず、GitHub Copilot の承認はマージの条件の数に入りません（GitHub の説明「必須のレビューがあるプルリクを承認する」）。ただし公開プレビューの Copilot の承認は、オンにすると数えられます（Copilot のレビュー）。このルールのもとでは、最後に push した人の承認も条件を満たしません。
変更の依頼：プルリクを必須にする規則があるとき、admin・owner・write の権限を持つ人が変更を依頼するレビューを出すと、同じ人が承認するまでマージできません。管理者か書き込み権限を持つ人はレビューを取り消せます。取り消すには理由のコメントが要り、取り消したレビューはレビューのコメントになります（GitHub の説明「プルリクのレビューを取り消す」）。

直す所

いま承認してもらう：最後に push した人以外が、今のプルリクを承認します。push の前に承認した人なら、もう一度承認するだけです。
どの承認が先頭のコミットにあるか見る：「List reviews for a pull request」の各レビューには、それが付いたコミットの commit_id があります。API でレビューを作るときに指定しなければ、プルリクの最新のコミットになります（GitHub の説明「プルリクのレビューの REST API」）。古いコミットへの承認は、先頭が動く前に出たものです。
push してから頼む：後の push の前に出た承認は、このルールを満たさなくなります。マージしたい形までブランチを整えてから承認を頼みます。
ほかのレビューの規則も止めることがある：承認の数が足りない、コードオーナーのレビュー（コードオーナーのレビュー）、未解決の会話（マージが会話の解決を待っている）です。

IntelliJ IDEA は承認を push と結び付けない

IntelliJ IDEA に入っている GitHub の機能が、新しい push の後の承認をどう扱うか。ソース（2026年10月31日に確認・IntelliJ IDEA：pullRequestReview.graphql・GHReviewersUtils.kt・GHPRReviewFlowViewModelImpl.kt・GraphQL のファイル・GithubApiRequests.kt）では：

ルールは読まない：78本の GraphQL のファイルのどれも requireLastPushApproval を頼まず、REST で送る物の一覧にもありません。
レビューのコミットは読まない：レビューごとに作者・本文・状態・日時を頼みますが、どのコミットに対するレビューかは頼みません。レビュアーごとに、日時の一番新しい承認か変更の依頼を取るので、最後の push より前の承認も、GitHub が取り消していなければ IDE では承認のままです。承認の数え方はマージがチームの承認を待っているの節にあります。
頼み直す：レビューを頼み直すコードは、もうレビューした人（作成者を除く）をレビュー依頼に戻します（レビュー依頼の送り方）。

IntelliJ IDEA で GitHub のプルリクを見るなら

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。プルリクのレビュー・チェック・会話を差分の隣に出し、対象のブランチが許す方法でマージします。GitHub がプルリクを blocked と言うときは、マージの確認に読める物を名指しします（報告の無い必須チェック・まだ要るレビュー・ルールが止めている未解決の会話と署名の無いコミット）。レビュアーの一覧では、前のコミットに対する承認にそう印を付けます。承認のあるプルリクが止まっていて、ブランチのルールセットか保護が最後の push の承認を求めているなら、マージの確認にそう出し、いまの先頭のコミットに承認があるかも出します。ルールが読めず、承認がどれも前のコミットに対するものなら、それがマージを止めているかもしれないと出します。受信箱・差分・会話は無料、承認・コメント・解決・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

GitHub は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。