GitHubでmainブランチを守ろう
Pull Requestを通して、安全にチーム開発を進める
GitHubを使ってチーム開発をするとき、特に大切なのが mainブランチを直接変更しないこと です。
個人で練習しているときは、mainブランチにそのままコミットしても大きな問題にならないことがあります。
しかし、チーム開発では違います。
mainブランチは、チーム全員が基準にする大切なブランチです。
そこに未確認のコードや、まだ動作確認ができていないコードが入ってしまうと、他の人の作業にも影響してしまいます。
例えば、次のようなことが起こる可能性があります。
- 他の人が pull したらエラーになる
- 自分の作業ブランチと競合する
- 誰が何を変更したのか分かりにくくなる
- レビューされていないコードが混ざる
そこで使うのが、GitHubの ブランチ保護 です。
mainブランチを保護するとは？
mainブランチを保護するとは、簡単に言うと、mainには直接pushせず、Pull Requestを通してからmainに入れる というルールをGitHub側で設定することです。
チーム開発では、次のような流れで作業します。
- 作業用ブランチを作る
- 自分の担当部分を作る
- コミットする
- pushする
- Pull Requestを作る
- レビューしてもらう
- mainにマージする
この流れにすると、mainブランチに入る前に、変更内容を確認できます。
GitHub Freeでも使えるのか？
GitHubの無料プランでも、条件によってブランチ保護を使うことができます。
2026年9月時点のGitHub公式ドキュメントでは、パブリックリポジトリであれば、GitHub FreeでもProtected branchesを利用できると説明されています。
一方で、プライベートリポジトリでProtected branchesを使う場合は、GitHub Pro、GitHub Team、GitHub Enterpriseなどのプランが対象とされています。
つまり、無料プランで学習用に使う場合は、次のように考えると分かりやすいです。
- 公開してよい教材・サンプルコード
→ パブリックリポジトリで作成し、ブランチ保護を使う - 公開できない課題や個人情報を含む内容
→ プライベートリポジトリにし、必要に応じて有料プランを検討する
授業で使う場合は、公開してよい内容かどうかを必ず確認しましょう。
ブランチ保護でできること
ブランチ保護を設定すると、mainブランチに対してルールを設定できます。
例えば、次のような設定があります。
- Pull Requestを必須にする
- レビュー承認を必須にする
- ステータスチェックの成功を必須にする
- force pushを制限する
- ブランチ削除を制限する
授業やチーム演習で特に大切なのは、次の2つです。
- Require a pull request before merging
- Require approvals
Require a pull request before merging は、mainブランチに直接変更を入れず、Pull Requestを通してからマージするための設定です。
Require approvals は、誰かのレビュー承認がないとmainにマージできないようにする設定です。
なぜmainに直接pushしてはいけないのか？
mainブランチは、チーム全員にとっての「基準」です。
そのため、mainに不完全なコードが入ると、他の人もその影響を受けます。
例えば、自分では動いたつもりでも、他の人がpullしたらエラーになることがあります。
また、プロジェクトファイルの保存漏れや、必要なファイルの追加漏れがあると、別の人の環境で正しく動かないこともあります。
Gitは、あとから履歴を確認したり、元に戻したりできる便利なツールです。
しかし、チーム開発では、問題が起きたら戻せばよい ではなく、問題が起きにくい進め方にする ことが大切です。
そのために、mainブランチを保護します。
Pull Requestは「面倒な手順」ではない
Pull Requestは、最初は少し面倒に感じるかもしれません。
しかし、Pull Requestは単なる手続きではありません。
Pull Requestには、次のような意味があります。
- 自分が何を変更したか説明する
- 他の人に確認してもらう
- mainに入れてよいか判断する
- チーム内で変更内容を共有する
つまりPull Requestは、コードを提出するためだけのものではありません。
チームで安全に開発するための確認場所です。
GitHub Desktopを使う場合
GitHub Desktopを使っている場合でも、考え方は同じです。
GitHub Desktopでは、主に次の操作を行います。
- ブランチを作る
- 変更内容を確認する
- コミットする
- pushする
- fetchする
- pullする
一方で、Pull Requestの作成、レビュー、mainへのマージは、GitHubのWeb画面で行うことが多いです。
役割を分けると、次のようになります。
- GitHub Desktop
→ 自分のパソコン上の作業をGitHubに送るための道具 - GitHubのWeb画面
→ Pull Requestを確認し、レビューし、mainにマージする場所
GitHub Desktopだけで完結させようとするのではなく、GitHubのWeb画面も使いながら、チーム開発の流れを確認しましょう。
設定の場所
GitHubでブランチ保護を設定するには、リポジトリの画面から次の場所に進みます。
- Settings を開く
- Branches を開く
- Add branch protection rule を選ぶ
- Branch name pattern に
mainを指定する
授業や演習では、まずは次の設定から始めると分かりやすいです。
- Require a pull request before merging
- Require approvals
これにより、mainブランチに直接pushするのではなく、Pull Requestを作成し、レビューを受けてからmainにマージする流れになります。
学習段階だからこそ大切
「まだ学習中だから、そこまで厳しくしなくてもよいのでは？」
と思う人もいるかもしれません。
しかし、学習段階だからこそ、この流れを経験しておく意味があります。
実務のチーム開発では、mainやmasterに自由に直接pushできない現場もあります。
作業ブランチを作り、Pull Requestを出し、レビューを受けてからマージする流れは、実際の開発でもよく使われます。
授業では、単にアプリを完成させるだけでなく、チームで安全に開発する流れを経験することも大切です。
まとめ
GitHubのブランチ保護を使うと、mainブランチへの直接pushを防ぎ、Pull Requestを通した安全な開発フローを作ることができます。
大切なのは、次の流れです。
- mainに直接pushしない
- 作業ブランチで作業する
- Pull Requestを作る
- レビューしてからmainにマージする
mainブランチは、チーム全員が使う大切な基準です。
だからこそ、自分だけの判断で直接変更するのではなく、Pull Requestを通して、チームで確認してから変更を入れるようにしましょう。
GitHub Desktopを使っている場合でも、この考え方は同じです。
GitHub Desktopで作業し、GitHubのWeb画面でPull Requestやレビューを確認することで、チーム開発の流れをより実感できます。
学習段階では、操作を早く済ませることよりも、正しい流れを経験することが大切です。
mainブランチを守ることは、チーム全体の作業を守ることにつながります。
参考
GitHub Docs「About protected branches」
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches