GitHubのブランチ保護設定：新UIでmainブランチを守る方法

チーム開発において、mainブランチの保護は必須の設定です。直接的なプッシュを防ぎ、プルリクエスト経由でのマージを強制することで、コードの品質を保ち、変更履歴を明確に管理できます。

GitHubが新しいUIに更新されたことで、設定方法も少し変わりました。この記事では、最新のインターフェースを使った具体的な手順を、実際の画面と共に説明していきます。

なぜブランチ保護が重要なのか

ブランチ保護を設定する前に、その重要性を理解しておきましょう：

• コードレビューの強制: すべての変更がレビューを経ることで、バグの早期発見や知識共有が促進される
• 変更履歴の明確化: プルリクエストによって、何が変更されたかが明確に記録される
• 事故の防止: 誤った直接プッシュによる本番環境への影響を防げる
• チーム開発の標準化: 全員が同じフローに従うことで、開発プロセスが統一される

設定手順（新UI版）

1. リポジトリの設定画面にアクセス

まず、保護したいリポジトリを開きます。

1. 対象リポジトリのページに移動
2. 上部メニューから Settings をクリック
3. 左メニューの Branches を選択

2. ブランチルールセットの作成

新しいUIでは「Branch protection rules」ではなく「Rulesets」という名前に変わっています。

1. Add branch ruleset ボタンをクリック

3. 基本情報の設定

ルールセット作成画面で、以下の項目を設定します：

① 基本情報

• Ruleset name: 任意の名前を入力（例: Protect main branch）
• Target branches: main を入力

この設定により、mainブランチにのみルールが適用されます。

4. 制限ルールの設定

② 制限ルール

以下の項目を有効にします：

Require a pull request before merging → ✅ ON

• オプション: Required approvals を 0 に設定（レビュー不要の場合）

Block force pushes → ✅ ON

5. 設定の保存

すべての設定が完了したら、Create をクリックして保存します。

設定後の動作確認

設定が正しく適用されているか、実際の動作で確認してみましょう：

直接プッシュの場合（拒否される）

# mainブランチに直接プッシュを試行
git checkout main
git add .
git commit -m "Direct commit to main"
git push origin main

結果: プッシュが拒否され、以下のようなエラーメッセージが表示されます：

remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Changes must be made through a pull request.

フィーチャーブランチの場合（成功する）

# フィーチャーブランチの作成とプッシュ
git checkout -b feature/new-functionality
git add .
git commit -m "Add new functionality"
git push origin feature/new-functionality

結果: 正常にプッシュされます。

プルリクエスト経由でのマージ（成功する）

1. GitHubでプルリクエストを作成
2. レビュー（Required approvalsを0に設定した場合は不要）
3. マージボタンをクリック

結果: mainブランチが正常に更新されます。

よくある質問と解決方法

Q: 管理者も直接プッシュできないの？

A: デフォルトでは管理者も制限されます。管理者のみ例外を許可したい場合は、ルールセット設定で「Bypass list」に管理者を追加できます。

Q: 緊急時にはどうすればいい？

A: 緊急時は以下の方法があります：

• 一時的にルールセットを無効化
• 管理者権限でルールをバイパス
• 緊急用のホットフィックスブランチを作成してプルリクエスト

Q: 既存のブランチ保護ルールとの違いは？

A: 新しいRulesetsは以下の利点があります：

• より柔軟な条件設定
• 複数ブランチへの一括適用
• より詳細な権限管理

まとめ

GitHubの新しいUIを使ったブランチ保護設定は、従来よりも直感的で分かりやすくなりました。特に「Required approvals」の設定場所が明確になったことで、設定ミスを防げるようになっています。

この設定により、以下のメリットが得られます：

• 安全性の向上: 直接的な変更を防ぎ、レビュープロセスを強制
• 品質の担保: すべての変更がプルリクエスト経由で記録される
• チーム協力の促進: 変更内容の共有とディスカッションが自然に行われる

チーム開発を始める際は、まずこのブランチ保護設定を行うことをお勧めします。最初は少し手間に感じるかもしれませんが、長期的には必ず開発効率と品質の向上につながります。

ヒント: 設定後は必ずチームメンバーに新しいワークフローを共有し、プルリクエストの作成方法を説明しておきましょう。