GitHub・プルリク・ルールセット・2026年10月26日に確認

GitHub：コミットのメタデータの規則がマージや push を止める

GitHub Enterprise のプランの組織は、コミットのメタデータの書き方を決める規則を足せます。対象はコミットのメッセージ・作者のメール・コミッターのメールと、新しいブランチとタグの名前です。規則に合わないコミットでブランチやタグを更新しようとすると、何が悪かったかを伝えるエラーが出ます。push したときはコマンドラインに、コミットを作ったりプルリクをマージしたりしたときは GitHub の上に出ます（GitHub の説明「ルールセットで使える規則」・2026年10月26日に確認）。

{ "type": "commit_message_pattern",
  "parameters": { "name": "Issue key", "operator": "starts_with",
                  "pattern": "SHOP-", "negate": false } }

規則

5つの種類：REST API では commit_message_pattern・commit_author_email_pattern・committer_email_pattern・branch_name_pattern・tag_name_pattern です。どれも operator（starts_with・ends_with・contains・regex）と pattern、任意の name、「〜してはいけない」を表す negate を持ちます（GitHub の説明「ルールの REST API」）。
文字どおりのパターン：「Must start with a matching pattern」のようなたいていの条件では、パターンは文字どおりに読まれ、ワイルドカードは使えません。* はただの * の文字です。
正規表現：「Must match a given regex pattern」か「Must not match a given regex pattern」を選ぶと、RE2 の書き方が使えます。既定では複数の行を見ません。^ABC は、1行目が ABC で始まる複数行のメッセージに合い、(?m) で始めると行をまたいで合わせます。否定の先読み ?! は使えません。行末の印には、$ だけでなく \n?$ を使うよう GitHub は勧めています。Git の push やコマンドラインの流れでは、末尾に改行が付くことがあるためです（GitHub の説明「コミットのメタデータの正規表現」）。
サインオフ：コミットのサインオフが必須だと、GitHub はコミットのメッセージに Signed-off-by: 名前 <メール> のような行を足すので、パターンとぶつかることがあります。

効き方

止めるのは push でなくブランチの更新：規則に合わないコミットを含む push は断られませんが、対象のブランチやタグは更新されません。コミットはリポジトリに入って開くこともできますが、ブランチやタグの履歴にはつながりません。同じ push のほかのブランチやタグは、そのコミットが規則に合えば更新されます。
新しいコミットだけ：既にあるブランチやタグに規則を足すと、それ以降に push される新しいコミットに効き、既にある履歴には効きません。
スカッシュマージ：GitHub の説明は、スカッシュマージではプルリクの個々のコミットは見ず、できる1つのコミットのメタデータだけを確かめ、プルリクの画面がマージを許す前にそれを確かめる、としています。同じ節の注記は、ブランチをスカッシュマージするなら、そのブランチのコミットはすべて対象のブランチのメタデータの条件を満たす必要がある、としています。
GitHub の上でのマージ：コミッターのメールの規則では、ウェブでのマージや GitHub の上で作られるほかのコミットのために、パターンが noreply@github.com も含む必要があります。

直す所

エラーのパターンを読む：コミットが断られると、メタデータが合うべきパターンがメッセージに出ます（GitHub の説明「ルールのトラブルシューティング」）。
コミットを作り直す：Git のコミットは変えられないので、作った後でメタデータを書き換えることはできません。リベースしてコミットをまとめるか、1つずつ書き直してから、新しいコミットを push する必要があることがあります。
スカッシュマージでは：GitHub はできるコミットを確かめるので、マージで付けるコミットのタイトルを、メッセージが規則に合うように書きます。コミッターのメールの規則があるなら、それが noreply@github.com を認めているかを確かめます。
規則を探す：リポジトリを読める人なら誰でも、有効なルールセットを見られます。リポジトリの設定の Rules → Insights には、ルールセットで確かめた操作と、失敗した操作ではどの規則が失敗したかが出ます（GitHub の説明「リポジトリのルールセットの管理」）。
管理者なら：GitHub は、メタデータの規則をすべての作業ブランチでなく、main だけのような限られたブランチに置き、そこへはプルリクを必須にするよう勧めています。まず「Evaluate」の状態で試すと、規則が有効だったら通ったか失敗したかが Insights に出ます。

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

Lesstep の Pull Request Inbox for GitHub は、JetBrains IDE（2024.1 以降）のプラグインです。プルリクのレビュー・チェック・会話を差分の隣に出し、対象のブランチが許す方法でマージします。マージの画面は、対象のブランチのコミットのメタデータの規則をコミットのタイトルの下に出し、どう書いても規則に合わないタイトル（決められた始まりでない、含んではいけない文字を含む）はその場で止めます。コミッターのメールの規則が noreply@github.com を認めていなければ、そう伝えます。規則を最後に確かめるのは GitHub です。受信箱・差分・会話は無料、承認・コメント・解決・マージは Pro（月 US$1.50・30日間の無料試用つき）です。画面は日本語です。

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