GitHub「Repository Rules」で守りを固める！開発スピードを落とさない究極のブランチ保護術
こんにちは。現場で数々の泥沼化したリリース事故を修復してきた経験から言わせてもらうと、「性善説に基づく開発」は、スケールした瞬間に必ず崩壊します。
特にチームが大きくなると、「うっかりmainに直pushしてしまった」「誰かが誤って履歴を書き換えた」といった事故は避けられません。そこで登場するのが、GitHubの「Repository Rules（リポジトリルール）」です。
これは従来の「Branch Protection Rules」をより強力に、かつ柔軟に進化させた次世代のガバナンス機能です。今日は、開発の自由度を殺さずに、壊してはいけない領域を鉄壁で守るための「必須設定」を伝授します。
—
1. なぜ「Repository Rules」なのか？
従来のBranch Protection Rulesは設定がリポジトリ単位で固定されがちで、柔軟性に欠けていました。一方、Repository Rulesは以下のようなメリットがあります。
- 柔軟な適用範囲: `main`だけでなく、`release/` や `feature/` など、パターンマッチングで複数のブランチを一括管理できる。
- ルールセットの再利用: 組織全体で共通のルールセットを定義し、複数のリポジトリに適用可能。
- 「バイパス」の細分化: 特定の権限を持つユーザーやアプリ（CIツールなど）だけに限定したバイパス設定が可能。
「開発者の邪魔をせず、事故だけを未然に防ぐ」——これこそがDevOpsの極意です。
—
2. 実践！必須の保護ルールセット構築
それでは、実際に設定していきましょう。GitHubのリポジトリ画面で `Settings` > `Rules` > `Rulesets` へ進んでください。
ステップ1：ルールセットの作成
1. `New ruleset` をクリックし、名前を付けます（例: `Production-Protection`）。
2. Enforcement status は、最初は `Evaluate`（適用せず監視のみ）でテストし、問題なければ `Active` に切り替えます。
3. Targets で対象ブランチを指定します。`Include default branch` を選択するか、`main` を指定しましょう。
ステップ2：破壊的変更を防ぐ「鉄板ルール」
以下のチェックボックスは、本番環境を守るための最低条件です。
- Restrict updates: `Allow force pushes` と `Allow deletions` を必ずオフにします。これだけで、履歴の改ざんという致命的な事故が物理的に不可能になります。
- Require a pull request before merging:
- `Require approvals`: 1人以上のレビューを必須にしましょう。
- `Dismiss stale pull request approvals when new commits are pushed`: これ重要です。 コードが修正されたら古い承認を無効化することで、レビュー後の「すり替え」を防ぎます。
- Require status checks to pass: CI（GitHub Actions等）が成功しない限りマージさせない設定です。テストなしのコードがmainに入ることはありません。
ステップ3：コミットの信頼性を担保する
- Require signed commits: 全てのコミットにGPG/SSH署名を強制します。これにより、「誰が書いたか」というコードの出自が保証され、なりすましを防げます。
—
3. 「HelloWorld」的な動作確認：設定が効いているか試す
設定が本当に効いているか、手元のターミナルで確認してみましょう。
1. 誤った操作を試みる（mainブランチで）
git checkout main
echo “hacked” >> README.md
git commit -am “Evil commit”
2. 強制プッシュ（Force Push）を試みる
git push origin main –force
期待される結果:
GitHubから `! [remote rejected] main -> main (protected branch hook declined)` というエラーが返ってきます。これが返ってくれば、あなたの守りは完璧です。
—
4. 現場で震えるほど役立つ「運用のコツ」
ルールを厳しくしすぎると、今度は「緊急対応できない」という別の問題が発生します。そこで、以下の運用ハックを覚えておいてください。
① 「バイパス」を賢く使う
`Rulesets` の設定の中に `Bypass list` があります。ここで、`Repository Admin` や特定の `GitHub App`（自動リリース用ツールなど）のみを許可するように設定します。人間には厳しく、自動化には道を空けておく。これがモダンな開発のあり方です。
② 変更履歴を管理する
ルールセット自体も「コード」として捉えてください。重要なルール変更は、チームメンバーに周知し、なぜそのルールを追加したのかをGitHubのIssueに残す習慣をつけましょう。
—
最後に：ツールに守らせ、人は創造する
GitHubのRepository Rulesは、単なる「制限」ではありません。「ここは絶対に壊れない」と確信できる場所があるからこそ、開発者は大胆に新しいコードを書けるのです。
最初は少し面倒に感じるかもしれませんが、一度設定してしまえば、あなたは「事故対応」という無駄な作業から解放されます。浮いた時間で、もっと面白いコードを書きましょう。
これをマスターすれば、あなたのチームのデプロイメントは確実に安定し、毎日の作業が劇的に楽になりますよ。さあ、今すぐ設定画面を開いてみてください！