GitHub・プルリク・署名されたコミット・2026年10月26日に確認

GitHub：署名の無いコミットがマージを止めている

ブランチの保護やルールセットは、署名されたコミットを求めることができます。そうすると、そのブランチに push できるのは、署名され検証されたコミットだけになります（人もボットも。GitHub の説明「保護されたブランチについて」と「ルールセットで使える規則」）。そのブランチへのプルリクにも同じ決まりが効きます。マージできるかを確かめるとき、GitHub はベースブランチの最新のコミットとプルリクの head のコミットを親にした試しのマージコミットを作り、その試しのマージで入るコミットを、head ブランチの物も含めて確かめます。そのため、head ブランチに署名の無いコミットがあると、最後のスカッシュコミットには GitHub が署名するのに、スカッシュマージでも止まることがあります。プルリクを開いた本人にも効くことがあります。GitHub はこういうプルリクを blocked と呼び、GraphQL の mergeStateStatus は BLOCKED（「The merge is blocked」）になります（2026年10月26日に確認）。

GET  /repos/OWNER/REPO/pulls/N/commits               → commit.verification.verified・reason（250件まで）
GET  /repos/OWNER/REPO/rules/branches/BRANCH        → 規則 "required_signatures"
GET  /repos/OWNER/REPO/branches/BRANCH/protection   → required_signatures.enabled

数に入るコミット

マージで入るコミット全部：head のコミットだけではありません。試しのマージで入る、head ブランチの古い署名の無いコミットも、最新のコミットと同じように止めます。
署名され、検証された物：GitHub は、署名され（GPG・SSH・S/MIME）、その署名の検証に成功したコミットを「Verified」とします。署名はあっても検証できなかったコミットは「Unverified」です（GitHub の説明「コミットの署名の検証について」）。署名の必須は、署名され検証されたコミット以外をすべて止めます。vigilant モードをオンにしていれば、GitHub が「Partially verified」とするコミットは通ります。
GitHub の上で作ったコミット：Web の画面で作ったコミットには GitHub が GPG で署名し、検証済みになります。GitHub App やボットのコミットは、アプリとして認証したリクエストで、作者・コミッター・署名を自分で指定していなければ検証済みになります。「Rebase and merge」では、GitHub が head ブランチのコミットから作り直したコミットを置きますが、本人の代わりに署名はできないので、署名の検証なしでベースブランチに入ります。文書にある回避策は、手元でリベースしてマージし、それを push することです。
一度検証されたら：署名されたコミットが push されて検証されると、GitHub は検証の記録を残します（REST API の verified_at）。あとで鍵を入れ替えたり、取り消したり、期限が切れたりしても記録は残り、GitHub は検証し直しません。

コミットが検証されない理由

理由：REST API のコミットには、verified と reason を持つ検証の情報が付いています。unsigned（署名が無い）、unknown_key（その鍵がどのユーザーのアカウントにも登録されていない）、no_user・unverified_email・bad_email（コミッターのメールアドレスがどのユーザーの物でもない・アカウントで確認されていない・鍵の ID に含まれていない）、expired_key、not_signing_key、malformed_signature、invalid、gpgverify_error・gpgverify_unavailable（検証の仕組みの側）です（GitHub の説明「コミットの REST API」）。
プルリクのコミット：「List commits on a pull request」は、コミットを250件まで、それぞれの commit.verification つきで返します。それより長いプルリクは、「List commits」で全部を取れます。
ルールの場所：ブランチの保護なら「Require signed commits」（required_signatures.enabled。「Get commit signature protection」は管理者かオーナーの権限で答えます）、ルールセットなら規則 required_signatures です。「Get rules for a branch」が、そのブランチに効いている規則の中に返します。

直す所

書き直して署名する：head ブランチの署名の無いコミットを、検証される署名つきで書き直し、force push します。署名を求めるブランチに署名の無いコミットを push したときの GitHub の案内も、リベースして検証される署名を入れ、force push することです。force push は、ほかの人がそのブランチの上に積んだ作業を消さないよう気をつけて行います。
先に原因を直す：unknown_key なら署名の鍵を GitHub のアカウントに登録し、メールアドレスの理由なら、鍵に含まれる確認済みのアドレスでコミットします。そのうえで署名し直します。
手元でスカッシュする：手元でスカッシュしてマージすることもできますが、できたコミットに署名してから push します。ほかの保護がプルリクを通した変更を求めているなら、その push には迂回の権限も要ることがあります。
迂回できる人に頼む：既定では、ブランチの保護の制限は、管理者の権限を持つ人や「bypass branch protections」の権限を持つロールには効きません（「Do not allow bypassing the above settings」をオンにすると効きます）。ルールセットは、迂回できる人を自分で決めます。当てはまる保護を迂回できる人なら、そのプルリクをマージできます。
ほかのルールも見る：署名は要件の1つにすぎません。承認のレビュー（コードオーナーのレビュー）、会話の解決（マージが会話の解決を待っている）、必須のチェック（必須チェックが Expected のまま）、ブランチを最新にしておくことも止める理由になります。

IntelliJ IDEA は署名の設定は取るが、署名そのものは読まない

IntelliJ IDEA に入っている GitHub の機能が、署名つきコミットの必須をどう扱うか。ソース（2026年11月1日に確認・IntelliJ IDEA：refUpdateRule.graphql・GHPRMergeabilityStateBuilder.kt・GraphQL のファイル・GithubApiRequests.kt）では：

ルール：マージ先（base）のブランチについて requiresSignatures を GitHub に頼みますが、プルリクをマージできるかを組み立てるコードがそのルールから使うのは、必須のチェック・自分が push できるか・必要な承認の数だけです。
コミット：78本の GraphQL のファイルのどれもコミットの signature を頼まず、REST で送る物の一覧にも署名の物は無いので、コミットが署名済みか・検証済みかを IDE は読みません。コミットごとに読む物は共同作者がコミットに数えられないの節にあります。

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

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

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