GitHub Rulesetsでmainブランチを保護する

2026年9月16日

mainへ直接Pushしないチーム開発の練習

チーム開発では、main ブランチを直接変更しない運用が大切です。

main ブランチは、チーム全員が共有する「完成版」に近い場所です。
各自が自由に main を変更してしまうと、他の人の作業とぶつかったり、動かない状態のコードが共有されたりする可能性があります。

そこでこの記事では、GitHub の Rulesets を使って、main ブランチを保護する方法を説明します。

GitHub には従来の Protected branches という機能もありますが、この記事では混乱を避けるため、現在の GitHub 画面に合わせて Rulesets に絞って説明します。

なぜ main ブランチを保護するのか

チーム開発では、次のような流れで作業します。

自分の作業ブランチを作る
↓
作業ブランチで変更する
↓
コミットする
↓
GitHubへPushする
↓
Pull Requestを作る
↓
レビューを受ける
↓
mainへMergeする

この流れにすることで、main ブランチに変更を入れる前に、他の人が内容を確認できます。

反対に、main ブランチへ直接Pushしてしまうと、次のような問題が起きやすくなります。

動かないコードがmainに入る
他の人の作業に影響する
誰が何を確認したのか分からない
レビューの練習にならない
チーム開発の流れを体験できない

授業や学習では、単にアプリを完成させるだけでなく、チーム開発の手順を経験することも重要です。

そのため、GitHub 側で main ブランチを保護し、直接Pushできないようにしておきます。

Rulesetsとは

Rulesets は、GitHub 上でブランチやタグに対してルールを設定する機能です。

たとえば、次のようなルールを設定できます。

mainブランチを削除できないようにする
mainブランチへ直接Pushできないようにする
Pull Requestを必須にする
レビュー承認を必須にする
force pushを禁止する

この記事では、初学者向けのチーム開発練習として、必要最低限の設定に絞ります。

今回の目標

今回の目標は、次の状態を作ることです。

mainブランチへ直接Pushできない
Pull Requestを作らないとmainへ反映できない
誰か1人のレビュー承認を必要にする
mainブランチの削除を防ぐ
force pushを防ぐ

この設定により、チームメンバーは必ず次の流れを通ることになります。

作業ブランチで作業
↓
Pull Request
↓
レビュー
↓
mainへMerge

設定画面を開く

GitHub の対象リポジトリを開きます。

その後、次の順に進みます。

Settings
↓
Rules
↓
Rulesets
↓
New branch ruleset

または、次のようなURLから開くこともできます。

https://github.com/ユーザー名/リポジトリ名/settings/rules/new?target=branch

たとえば、TeamQuizApp の場合は、ブランチ用の ruleset 作成画面を開きます。

Ruleset Name

まず、Ruleset の名前を入力します。

おすすめは次の名前です。

Protect main branch

意味は「main ブランチを保護する」です。

日本語で考えると、

mainブランチ保護

という意味になります。

GitHub 上の設定名なので、英語の Protect main branch にしておくと自然です。

Enforcement status

次に、Enforcement status を設定します。

これは、作成したルールを実際に有効にするかどうかを決める項目です。

授業で実際に main ブランチへの直接Pushを防ぎたい場合は、Active を選びます。

最初に設定を試したい場合は Evaluate でもよいですが、練習として確実にルールを適用したい場合は Active が分かりやすいです。

Bypass list

Bypass list は、ルールを回避できる人を指定する場所です。

たとえば、先生や管理者だけはルールを回避できるようにすることもできます。

ただし、授業では最初は 空のまま でよいです。

理由は、例外を作ると説明が複雑になるからです。

先生だけは直接mainを変更できる
生徒は直接mainを変更できない

という状態にすると、初学者には少し分かりにくくなります。

まずは、全員が同じルールで運用する方が理解しやすいです。

Target branches

Target branches では、どのブランチにルールを適用するかを決めます。

ここがとても重要です。

初期状態で、

Include: All branches

になっている場合があります。

これは「すべてのブランチにルールを適用する」という意味です。

しかし、授業用のチーム開発では、これは強すぎる可能性があります。

なぜなら、各メンバーは自分の作業ブランチを作って、自由にコミットやPushをする必要があるからです。

今回守りたいのは、すべてのブランチではありません。

守りたいのは、

main

です。

そのため、Target branches は次のどちらかにします。

Include default branch

または、

Include by pattern: main

通常、リポジトリの標準ブランチが main であれば、Include default branch で問題ありません。

考え方としては、次のようになります。

mainブランチ
→ 保護する

featureブランチ、作業ブランチ
→ 各自が作業できるようにする

設定するRules

今回の授業用では、次のルールを設定します。

Restrict deletions
Require a pull request before merging
Block force pushes

さらに、Pull Request の設定内で、

Required approvals: 1

を設定します。

Restrict deletions

Restrict deletions は、対象ブランチを削除できないようにする設定です。

main ブランチは、チーム全体の中心になるブランチです。

誤って削除されると、チーム全体に影響します。

そのため、これは オン にします。

✅ Restrict deletions

Require a pull request before merging

Require a pull request before merging は、今回もっとも重要な設定です。

これは、main ブランチへ変更を入れる前に、Pull Request を必須にする設定です。

この設定をオンにすると、作業の流れは次のようになります。

mainに直接Pushする
→ できない

作業ブランチでPushする
→ Pull Requestを作る
→ レビューを受ける
→ mainにMergeする

つまり、チーム開発の基本的な流れを練習できます。

✅ Require a pull request before merging

Required approvals

Require a pull request before merging をオンにすると、レビュー承認に関する設定が表示されます。

授業用では、次の設定がおすすめです。

Required approvals: 1

これは、Pull Request を main に取り込む前に、誰か1人の承認が必要になる設定です。

この設定により、次の練習ができます。

他の人のコードを読む
変更内容を確認する
問題がなければApproveする
必要ならコメントする

ここで大事なのは、レビューは相手を責めるためのものではないということです。

レビューは、チームで安全に作業するための確認です。

また、Require a pull request before merging をオンにすると、Required approvals 以外にも、いくつかの詳細設定が表示されます。ここでは、それぞれの意味と、授業での扱い方を補足しておきます。

Dismiss stale pull request approvals when new commits are pushed

承認後に新しいコミットが追加された場合、それまでの承認を無効にする設定です。たとえば、Aさんが Pull Request を出し、BさんがApproveした後にAさんが追加修正をPushすると、Bさんの承認が取り消され、もう一度レビューが必要になります。

実務では有効な設定ですが、初学者向けの授業では少し厳しめです。最初はオフ でよいです。

Require review from specific teams

特定のチームによるレビューを必須にする設定です。GitHub Organization でチームを作っている場合などに使いますが、授業用の個人リポジトリや少人数の練習では、基本的に不要です。オフ のままでよいです。

Require review from Code Owners

CODEOWNERS ファイルで指定された担当者のレビューを必須にする設定です。ファイルごとに責任者を決める運用で、実務では使うことがありますが、初学者向けの授業では設定が増えて混乱しやすいため、今回はオフ で問題ありません。

Require approval of the most recent reviewable push

最新のPushをした本人以外の誰かが承認しないとマージできない設定です。たとえば、AさんがPRを出してBさんがApproveした後にAさんが追加修正をPushした場合、その最新の変更もAさん以外の誰かが承認する必要があります。

実務では安全性が上がる良い設定ですが、授業では最初はRequired approvals: 1 だけで十分です。

Require conversation resolution before merging

Pull Request 上のレビューコメントや会話をすべて解決してからでないとマージできない設定です。レビューの練習としては良い設定ですが、初学者には操作が増えるため、最初はオフ でよいです。レビューコメントの運用に慣れてきたら、オンにしてもよいでしょう。

Require an additional approval for unattributed Copilot pull requests

Copilot が人間の共同作業者なしで Pull Request を作った場合に、追加承認を要求する設定です。授業で Copilot に Pull Request を作らせる運用をしていなければ不要です。Preview 表示の試験的な機能でもあるため、現時点ではオフ のままで構いません。

授業用での扱いをまとめると、次のとおりです。

まずは、Pull Request を作り、誰かが内容を確認して承認してから main に取り込む、という流れを経験することを優先します。

Block force pushes

Block force pushes は、force push を禁止する設定です。

force push は、Git の履歴を書き換える強い操作です。

慣れていない状態で使うと、他の人の作業履歴に影響する可能性があります。

授業では、基本的に force push は使わない方が安全です。

そのため、これは オン にします。

✅ Block force pushes

今回は設定しないRules

Rulesets の画面には、ほかにも多くのルールがあります。

しかし、初学者向けの授業では、最初から全部を設定する必要はありません。

Restrict creations

対象ブランチの作成を制限する設定です。

今回守りたい main ブランチは、すでに存在している前提です。

そのため、今回は設定しません。

オフでよい

Restrict updates

対象ブランチの更新を、bypass 権限を持つ人だけに制限する設定です。

これは強い制限です。

初学者向けの授業では、Pull Request のマージ操作まで分かりにくくなる可能性があります。

今回は、Require a pull request before merging で十分です。

オフでよい

Require linear history

履歴を一直線に保つため、マージコミットを禁止する設定です。

現場では使うことがあります。

ただし、初学者には次の違いまで説明が必要になります。

Create a merge commit
Squash and merge
Rebase and merge

今回は、まず Pull Request とレビューの流れを理解することが目的なので、設定しません。

オフでよい

Require deployments to succeed

デプロイが成功してからでないと、対象ブランチへ反映できないようにする設定です。

Webアプリや本番環境があるプロジェクトでは有効ですが、今回のような学習用アプリでは不要です。

オフでよい

Require signed commits

署名付きコミットを必須にする設定です。

セキュリティを高める設定ですが、GitHub Desktop や Git の署名設定について追加説明が必要になります。

初学者向けの授業では、最初は不要です。

オフでよい

Require status checks to pass

テストやビルドなどのチェックが成功しないと、マージできないようにする設定です。

GitHub Actions などの自動チェックを設定している場合に使います。

まだ自動ビルドや自動テストを設定していない場合は、今回は不要です。

オフでよい

Require code scanning results

セキュリティスキャンの結果を要求する設定です。

CodeQL などを使った本格的なセキュリティ確認向けです。

授業の最初の段階では不要です。

オフでよい

Require code quality results

コード品質分析の結果を要求する設定です。

これも本格的な開発運用向けです。

授業の最初の段階では不要です。

オフでよい

Restrict code coverage

テストカバレッジの最低ラインを設定する項目です。

単体テストやカバレッジ測定を導入している場合に使います。

今回は不要です。

オフでよい

Automatically request Copilot code review

Pull Request 作成時に、Copilot にコードレビューを自動依頼する設定です。

便利な機能ですが、全員が同じ環境で Copilot を使えるとは限りません。

授業では、まず人間同士のレビューを経験する方が大切です。

オフでよい

最終的なおすすめ設定

今回の授業用では、次の設定にします。

Ruleset Name:
Protect main branch

Enforcement status:
Active

Bypass list:
空のまま

Target branches:
Include default branch
または
Include by pattern: main

Rules:
✅ Restrict deletions
✅ Require a pull request before merging
   ✅ Required approvals: 1
✅ Block force pushes

この設定により、次の状態になります。

mainブランチを直接更新できない
Pull Requestが必要になる
レビュー承認が必要になる
mainブランチを削除できない
force pushできない

生徒向けの説明

この設定は、誰かを疑うためのものではありません。

チーム開発では、main ブランチを安定した状態に保つ必要があります。

そのため、変更はすぐに main へ入れるのではなく、作業ブランチで行い、Pull Request を作ってから確認します。

mainは完成版の置き場
作業は自分のブランチで行う
Pull Requestで変更内容を見てもらう
レビュー後にmainへ取り込む

この流れを経験することが、チーム開発の練習になります。

GitHub Desktopとの関係

GitHub Desktop は、ブランチ作成、コミット、Push、Fetch、Pull などを行うための道具です。

一方、Rulesets は GitHub 側でチームのルールを決める設定です。

GitHub Desktop
→ 作業するための道具

GitHub Rulesets
→ mainを守るためのルール

GitHub Desktop だけでは、main に直接Pushしないように「お願い」する形になります。

しかし、Rulesets を設定すると、GitHub 側で main ブランチを保護できます。

つまり、

直接mainにPushしないでください

ではなく、

直接mainにPushできないようにする

ことができます。

GitHub Freeプランで使えるか

GitHub Free でも、パブリックリポジトリであればブランチ保護に関する機能を利用できます。

そのため、授業用リポジトリが public であれば、無料プランでも main ブランチを保護する運用を練習できます。

一方で、プライベートリポジトリの場合は、利用できる機能がプランによって異なる場合があります。

授業で使う場合は、リポジトリを public にするか、使用しているプランで Rulesets が利用できるかを確認しておくと安心です。

まとめ

GitHub Rulesets を使うと、main ブランチを安全に保護できます。

今回の授業では、次の3つを中心に設定します。

Pull Requestを必須にする
レビュー承認を1人以上必要にする
force pushと削除を防ぐ

これにより、チーム開発で大切な流れを自然に練習できます。

作業ブランチ
↓
コミット
↓
Push
↓
Pull Request
↓
レビュー
↓
mainへMerge

アプリを作ることだけが目的ではありません。

チームで安全に変更を進める流れを経験することも、重要な学習です。

参考

• GitHub Docs：About rulesets
• GitHub Docs：Available rules for rulesets
• GitHub Docs：About protected branches

※この記事では、現在の GitHub 画面に合わせて Rulesets を使って説明しています。Protected branches は従来からある関連機能ですが、操作手順が混ざると分かりにくくなるため、本文では Rulesets に絞っています。