「mainブランチに直接pushされてレビューが飛んだ」「テストが落ちたままマージされた」。こうした事故を減らしたいときに使えるのが、GitHubのRulesetsです。
とはいえ、従来のブランチ保護との違いや、どのルールから入れるべきかは迷いますよね。結論は「mainに絞って必要最小限から始める」こと。
設定手順と確認方法、つまずきやすい点を整理します。
Rulesetsは重要なブランチへの変更条件をまとめる機能
Rulesetsは、ブランチやタグに対して「変更するときに守ってほしい条件」を、名前付きのルール群としてまとめる機能です。
mainへの変更はプルリクエスト経由に限る、指定したステータスチェックが通るまでマージを許さない、といった条件が代表例です。
force pushや削除の制限も含めて、複数の条件を1つのRulesetにまとめられます。
1つのリポジトリには最大75個まで作れますが、個人や小規模チームなら1つか2つで十分でしょう。
注意したいのは、Rulesetsがコードの品質そのものを保証する仕組みではない点です。テストはGitHub Actionsなど別の仕組みで動かし、Rulesetsは「その結果をマージ条件にする」役割を受け持ちます。
どのレビューやテストを必須にするかを決めるのは、あくまで運用する側です。
最初はmainブランチに必要最小限のルールを設定する
個人開発や小規模チームなら、最初から多くのルールを入れる必要はありません。次の順番で検討すると、設定の目的を見失いにくくなります。
- 守りたい対象をmainブランチに絞る
- 変更をプルリクエスト経由にするか決める
- 自動テストがすでにある場合だけ、必要なステータスチェックを指定する
- ブランチ削除とforce pushを制限する
- 緊急対応用のバイパス権限が本当に必要かを確認する
ルールを増やすほど安全になるとは限りません。動いていないテストを必須にすると、チェック結果が返らずマージできなくなります。
承認者が1人しかいないのに複数レビューを必須にすれば、普段の更新まで止まってしまうでしょう。
大切なのは「一般的に厳しい設定」ではなく、「このリポジトリで防ぎたい事故」を先に言葉にすることです。
直接pushを避けたいのか、CIの失敗を見逃したくないのか、履歴を書き換えられたくないのか。目的によって、選ぶルールは変わります。
Rulesetsと従来のブランチ保護の違い
GitHubにはRulesetsのほかに、以前からのブランチ保護ルール(Branch protection rules)があります。
どちらもブランチを守る機能で、両方が同じブランチに設定されていれば、すべてのルールが有効になります。では何が違うのかというと、主に管理と確認のしやすさです。
- 複数を同時に適用できる
-
同じブランチに複数のRulesetを重ねられます。ブランチ保護ルールは、1つのブランチに1つだけです。
- 削除せずに止められる
-
適用状態をActiveからDisabledへ切り替えれば、ルールを残したまま無効にできます。切り分けのときに便利ですね。
- 開発者も内容を見られる
-
読み取り権限があれば、アクティブなRulesetを確認できます。管理者しか設定を把握していない状態を避け、「なぜこの変更が拒否されたのか」を追いやすくなります。
既存のブランチ保護ルールがあるリポジトリでも、すぐに置き換える必要はありません。
両方が並行して効くため、移行するときは追加したRulesetだけでなく、最終的に重なった条件まで確認しておきましょう。
同じ種類のルールで条件が違う場合は、より厳しい方が適用されます。
ブランチ用Rulesetを作る手順
ここでは、リポジトリのmainブランチを対象にする流れを整理します。
GitHubの画面表示は変わることがあるので、実際に設定するときは対象リポジトリで最新の名称を確認してください。作業は次の5ステップです。
SettingsからRulesetsを開く
対象リポジトリの「Settings」を開き、左側の「Code and automation」にある「Rules」から「Rulesets」を選びます。
「New ruleset」を押すと、ブランチ向けの「New branch ruleset」とタグ向けの「New tag ruleset」を選べます。今回はブランチ向けです。
Settingsタブが見えない場合は、リポジトリの管理権限があるかを確認しましょう。Rulesetの作成・編集・削除には、adminアクセスか、「edit repository rules」権限を持つカスタムロールが必要です。
名前と適用状態を決める
「Ruleset name」には、対象と目的がわかる名前を付けます。「main-protection」のような短い名前でも構いません。複数のRulesetを使うなら、「main-pr-and-ci」のように内容を想像できる名前の方が管理しやすいでしょう。
適用状態は「Active」と「Disabled」から選びます。Activeで作成すると、その時点から対象ブランチに適用されます。Disabledならルールは効きません。
設定内容を先に保存して関係者に見せたいときや、既存ルールとの重なりを整理してから有効にしたいときは、Disabledで準備しておく方法もあります。
対象ブランチを指定する
「Target branches」で、Rulesetを適用するブランチを選びます。
デフォルトブランチを指定する方法のほか、名前のパターンで対象を含めたり除外したりでき、1つのRulesetに複数の条件を追加することも可能です。
mainを守りたいだけなら、広いワイルドカードから始めず、デフォルトブランチなど対象を限定するのがおすすめです。
意図せず作業ブランチまで厳しいルールの対象に入れると、開発途中のpushまで止まってしまいます。
バイパス権限を必要最小限にする
「Bypass list」では、Rulesetを例外的に回避できる主体を指定します。リポジトリ管理者などのロール、チーム、GitHub Apps、Dependabotなどが候補です。
主体によっては、直接pushは許さず、プルリクエスト経由でのみバイパスできる設定も選べます。
バイパスは、ルールが原因で緊急修正できない事態を避けるために役立ちます。一方で、広く許可するとRulesetを設けた目的が薄れてしまいます。
「管理者だから常に回避できる」と決めるのではなく、誰が、どの場面で、なぜ必要かを先に整理しておくのがポイントです。
保護ルールを選んで作成する
「Branch protections」で必要なルールを選びます。すべてにチェックを入れるのではなく、現在の開発フローで確認できるものだけに絞りましょう。
設定内容を見直したら「Create」を押します。状態がActiveなら、その時点で対象ブランチに適用されます。
作成後は、実際のブランチにどのRulesetがかかっているかを別画面で確認しておくと安心です。
初心者が検討しやすいルール
Rulesetsで選べるルールは多くありますが、最初に候補へ入るのはプルリクエスト、ステータスチェック、削除制限、force push制限の4つです。
それぞれ何を防ぐためのルールかを押さえておくと、自分のリポジトリに必要かどうかを判断しやすくなります。
プルリクエストを必須にする
「Require a pull request before merging」は、対象ブランチへの変更をプルリクエストに関連付けるルールです。
プルリクエストを開くこと自体を必須にでき、追加設定で必要な承認数なども調整できます。
個人開発でも、mainへ直接pushせず、差分を一度プルリクエストで見る流れを作れます。第三者のレビューがなくても、変更理由と差分が記録として残るのは意味があります。
ステータスチェックの成功を必須にする
「Require status checks to pass before merging」は、指定したCIテストが通るまでマージを許可しないルールです。必須にするチェックは名前で指定します。
先にGitHub Actionsなどで安定して動くチェックを用意し、その正確な名前を確認してからRulesetへ追加しましょう。
まだCIがないリポジトリなら、このルールを先に有効にするのは避けた方が安全です。プルリクエスト運用から始め、チェックが安定してから追加する順番がおすすめです。
ブランチ削除を制限する
「Restrict deletions」は、対象に一致するブランチやタグを削除できる人を、バイパス権限を持つ人だけに制限します。mainやリリース用タグを誤って消してしまうリスクを下げたいときに検討しましょう。
force pushをブロックする
「Block force pushes」は、対象ブランチやタグへのforce pushを防ぐルールです。
force pushは履歴を書き換えるため、ほかの人が基準にしていたコミットが履歴から外れ、競合やプルリクエストの不整合につながります。
mainのように共有の基準になるブランチでは、明確な理由がない限りブロックしておく方が運用を説明しやすいでしょう。
必要に応じて履歴や署名のルールを追加する
このほか、直線的な履歴を求める「Require linear history」も選べます。署名済みコミットを求める「Require signed commits」も同様です。
ただし、直線的な履歴を必須にするには、リポジトリ側でsquash mergeかrebase mergeを許可している必要があります。
署名済みコミットも、参加者や自動化ツール側の準備が欠かせません。導入理由をチームで説明できる段階になってから追加する方が、設定だけが先行せずに済みます。
作成後は「実際に何が適用されるか」を確認する
Rulesetは作って終わりではありません。対象ブランチに、既存のRulesetやブランチ保護ルールと重なった結果として何が効いているかを確認します。
確認方法は3つあります。1つ目は、リポジトリのブランチ一覧です。Rulesetがあるブランチにはアイコンが付き、そこから内容を開けます。
2つ目は、リポジトリURLの末尾に「/rules」を付ける方法で、アクティブなRulesetを一覧できます。3つ目はプルリクエストのマージ欄で、ルールがマージを止めている場合はその情報が出るのです。
管理者なら「Settings」の「Rules」から「Rulesets」へ進み、名前、対象、バイパス、各ルールを再確認できます。
変更が想定外に止まったときは、すぐRulesetを削除せず、対象条件、既存ルールとの重なり、チェック名、バイパス対象の順に見直しましょう。
切り分けのために一時停止したいなら、Disabledへの変更で十分です。
Rulesetの影響を記録から追う画面もあります。「Settings」の「Rules」にある「Insights」を開くと、「Rule Insights」が表示されます。
ここで、Rulesetの確認を通過した操作、失敗した操作、バイパスされた操作を時系列で追えます。
ただし、グラフで傾向を見るダッシュボードはGitHub TeamとGitHub Enterprise Cloud向けです。個人アカウントで使う場合は、実際に表示される画面を確かめてください。
設定前に知っておきたい注意点
実際に設定してみると、ルールそのものより「周辺の前提」でつまずくことが多いものです。特に次の4点は、作成前に確認しておくと手戻りが減ります。
複数のルールは上書きではなく重なる
Rulesetには優先順位がありません。同じブランチやタグを対象にするRulesetは集約され、従来のブランチ保護ルールも一緒に効きます。
新しいRulesetの設定だけを見ると問題がなくても、既存ルールと組み合わさって想定より厳しくなることがあるのです。
- 既存の保護を消してから試すのではなく、まず現在の適用条件を一覧にする
- 削除は復元や比較を難しくするため、無効化できるRulesetは状態変更で段階的に確認する
- 同じ種類のルールで条件が違う場合は、より厳しい方が適用される
ステータスチェックは名前と実行条件を確認する
必須チェックは、指定したチェックが実際に実行され、結果を返すことが前提です。
ワークフロー名やジョブ名を変えた、特定ファイルの変更時しかCIが走らない、外部サービスを止めたといった事情で、必要な結果がそろわないことがあります。
Rulesetへ追加する前に、通常のプルリクエストでチェックが安定して完了するかを確かめておきましょう。
ルール導入後にマージできなくなった場合も、コードだけでなくチェックの起動条件を見直すのがポイントです。
バイパスを通常運用にしない
毎回バイパスしている状態は、ルールと実際の開発フローが合っていないサインです。例外対応を記録しておき、同じ理由が続くなら承認数、対象ブランチ、CI構成のどれかを見直します。
利用できる範囲はプランと公開範囲で異なる
2026年9月9日時点で、Rulesetsを使えるのは次の範囲です。GitHub FreeとGitHub Free for organizationsでは公開リポジトリのみ。
GitHub Pro、GitHub Team、GitHub Enterprise Cloudでは、公開・非公開の両方で利用できます。push rulesetsやRule Insightsのダッシュボードには、別の提供条件があります。
画面に項目がない場合は、操作手順の間違いだけでなく、リポジトリの公開範囲、契約プラン、権限を確認してみてください。
料金や提供条件は変わる可能性があるので、実際に設定する時点でGitHubのプラン案内も見直しておくと安心です。
Rulesetsが向く運用・別の方法が向く運用
Rulesetsは、次のような運用に向いています。
- mainやreleaseブランチへの変更条件を明確にしたい
- プルリクエストとCIをマージ条件としてそろえたい
- ブランチやタグごとに異なる保護を設定したい
- 複数のRulesetが重なった状態を開発者にも見えるようにしたい
- バイパスできる人やアプリを限定したい
一方、GitHub上での共同作業をまだ始めておらず、ローカルにしかリポジトリがない段階もあるでしょう。
その場合は、Rulesetsより先にGitHubへのpush、ブランチ分け、プルリクエストの基本を整える方が実務的です。
自動テストを回していないリポジトリで必須ステータスチェックを入れるのも順番が逆で、まずCIを安定させる必要があります。
mainへの直接pushだけを避けたい既存リポジトリなら、今のブランチ保護ルールをそのまま続ける判断もあります。
Rulesetsは従来の保護を必ず置き換えるものではありません。管理対象が増えた、複数のルールを重ねたい、適用内容を開発者にも見せたい、といった場面で検討すると導入理由が明確になります。
まとめ
GitHub Rulesetsを使うと、特定のブランチやタグに対して変更の条件をまとめて適用できます。プルリクエスト、ステータスチェック、削除、force pushの制限が代表的なルールです。
複数のRulesetや従来のブランチ保護ルールは重なって効くため、作成画面だけでなく最終的な適用結果の確認が欠かせません。
最初の一歩は、mainブランチで防ぎたい事故を1つか2つに絞ること。対象を限定し、実際の開発フローで守れるルールだけを有効にします。
作成後はブランチ一覧や「/rules」で適用内容を確認し、通常のプルリクエストが問題なく完了するかを試してから、追加のルールを検討してください。
