前回（No.6：Pull Request（PR）とコードレビュー）では、プルリクエストを使ったレビュー文化について解説しました。
第7回となる今回は、チーム開発の「交通ルール」である 「ブランチ戦略」 について解説します。
「mainブランチに直接コミットしていいの？」「developって何？」といった疑問を持ったことはありませんか？
チームの規模やリリース頻度に合わせて適切なルールを敷くことで、開発スピードと安全性の両立が可能になります。
GitHub入門シリーズ 全10回
本記事は「GitHub入門」全10回のNo.7です。
- No.1：Git/GitHubの基本概念とGitHub導入による投資対効果(ROI)
- No.2：リポジトリとREADMEから始める
- No.3：変更を確定！コミット実行とコミットメッセージの書き方
- No.4：VS CodeでGitを使いこなす マージ・コンフリクト・便利機能
- No.5：Issue（イシュー）でタスク管理
- No.6：Pull Request（PR）とコードレビュー
- No.7：ブランチ戦略の比較 Git Flow、GitHub Flow、GitLab Flow
- No.8：GitHub Actions CI/CDで自動化
- No.9：Code Scanning・Dependabot セキュリティの自動化
- No.10：なぜGitHubが高パフォーマンスチームを作るのか
今回のゴール
- Git Flow / GitHub Flow / GitLab Flow の詳細な違いを理解する
- チームの状況に合わせて最適な戦略を選択できる
- 「ブランチ保護ルール」を設定し、事故をシステム的に防ぐ
- GitHub Releasesを使ってバージョン管理を行う
1. なぜ「戦略」が必要なのか？
もしブランチのルールがないと、以下のような混乱が起きます。
- 「Aさんの機能、まだテスト中なのに本番環境に入っちゃった！」
- 「緊急のバグ修正をしたいけど、
mainブランチが開発中のコードで汚れていてリリースできない…」
こうした事故を防ぎ、「いつ、何を、どこにマージするか」 を決めたルールがブランチ戦略です。
導入することで、「どこからブランチを切ればいい？」と迷う時間がゼロになり、意思決定が高速化します。
2. 代表的なブランチ戦略の詳細比較
ここでは、主要な3つの戦略について、具体的なブランチ構成と開発フローを解説します。
GitHub Flow
Web開発における事実上の標準（デファクトスタンダード）です。非常にシンプルで、「mainブランチは常にデプロイ可能である」 という哲学に基づいています。
ブランチの役割と命名規則
| ブランチ名 | 命名規則 | 役割・寿命 |
|---|---|---|
| Main | main |
本番環境そのもの。常に正常に動作し、いつでもリリースできる状態を保つ。 |
| Feature | feature/xxx |
新機能開発やバグ修正用。作業が終われば mainにマージして削除される。 |
開発の流れ
-
mainブランチから、作業用のfeatureブランチを作成する - 機能実装を行い、コミットする
-
mainに対してプルリクエスト（PR）を作成する - レビューが完了したら
mainにマージする - マージされたら即座に本番環境へデプロイ（リリース）する
- 向いているケース: Webサービス、SaaSなど、1日に何度もデプロイしたい場合
Git Flow
歴史があり、最も厳格で複雑なモデルです。「開発中の状態」と「リリースの状態」を完全に分離します。
ブランチの役割と命名規則
| ブランチ名 | 命名規則 | 役割・寿命 |
|---|---|---|
| Main | main |
リリース済みの製品。ユーザーが使っているコードと完全に一致する。 |
| Develop | develop |
開発の合流地点。次のリリースに向けた機能がここに集まる。 |
| Feature | feature/xxx |
各機能の開発用。developから切り、developにマージする。 |
| Release | release/v1.x |
リリース準備用（バージョン番号の変更や最終テスト）。developから切る。 |
| Hotfix | hotfix/xxx |
本番環境の緊急バグ修正用。mainから切り、修正後はmainとdevelop両方に戻す。 |
開発の流れ
- 開発者は
developからfeatureブランチを作成し、実装する - 作業完了後、
developにマージする - リリース時期が来たら、
developからreleaseブランチを作成する - 最終テストを行い、完了したら
mainとdevelopの両方にマージする -
mainにタグ（v1.0.0など）を打ち、リリースする
- 向いているケース: スマホアプリ、デスクトップアプリ、組み込みソフトなど、リリース日が決まっており、バージョン管理が厳密な場合
GitLab Flow
GitHub Flowをベースにしつつ、「環境（Environment）」と「ブランチ」を1対1で対応させるモデルです。
検証環境（Staging）での確認プロセスを必須とする場合に適しています。
ブランチの役割と命名規則
| ブランチ名 | 命名規則 | 役割・デプロイ先 |
|---|---|---|
| Main | main |
開発の主軸。機能はここにマージされる。必要に応じて開発環境へデプロイされる。 |
| Staging | staging |
検証環境用。リリースの前にテストを行う場所。mainからマージされる。 |
| Production | production |
本番環境用。検証完了後、stagingからマージされデプロイされる。 |
開発の流れ
-
開発:
mainからfeatureブランチを切り、開発・マージする（ここはGitHub Flowと同じ） -
検証: リリース候補が決まったら、
mainをstagingブランチへマージする。検証環境へ自動デプロイされる -
本番: ステージングでの検証に合格したら、
stagingをproductionブランチへマージする。本番環境へデプロイされる
- 向いているケース: 受託開発、大規模なWebシステム、品質保証（QA）チームによる検証期間が必要なプロジェクト
結論：どれを選べばいい？
迷ったら、まずは 「GitHub Flow」 から始めることを強くお勧めします。
シンプルであることは正義です。開発規模が大きくなり、「検証環境でのテスト期間をしっかり確保したい」という課題が出てきた段階で、GitLab FlowやGit Flowへの移行を検討しましょう。
3. 安全装置「ブランチ保護ルール」
人間は必ずミスをします。「誤ってmainブランチを削除してしまった」「レビューなしでマージしてバグらせてしまった」…
こうした事故を精神論ではなくシステム的に0%にするのが、GitHubの Branch protection rules（ブランチ保護ルール） です。
設定方法
- リポジトリの Settings > Branches > Add branch protection rule をクリック
-
Branch name pattern に
mainと入力 - 以下の項目にチェックを入れるのが推奨設定です
-
Require a pull request before merging:
- PRを通さないとマージできなくします
- Require approvals: 必須レビュー人数（例: 1人）を設定
-
Require status checks to pass before merging:
- テスト（CI）が通らないとマージボタンを押せなくします
-
Block force pushes:
- force pushを禁止します
CODEOWNERS（コードオーナー）
特定のファイル（例: DB関連）を変更する際に、必ず特定のメンバー（例: リードエンジニア）のレビューを必須にする機能です。
リポジトリに.github/CODEOWNERSというファイルを置くことで設定できます。
# データベース関連は @db-team の承認が必須
/db/ @db-team
# 全てのJSファイルは @frontend-lead が見る
*.js @frontend-lead
4. Releases機能でリリースを管理する
開発がひと段落し、本番へリリースするタイミングで Releases 機能を使いましょう。
Gitの「タグ（Tag）」機能と連動し、ソースコードの特定時点にv1.0.0などの名前をつけて保存できます。
自動リリースノート生成
GitHubには便利な機能があります。Release作成画面で 「Generate release notes」 ボタンを押すと、前回のリリースからの変更点（マージされたPR一覧）を自動でリストアップしてくれます。
これにより、「今回のリリースにはどの機能が含まれているんだっけ？」という確認の手間がなくなります。
まとめ
今回は、チーム開発の交通ルールであるブランチ戦略について解説しました。
- GitHub Flow: 最もシンプルで高速。Web開発の基本
- Git Flow: バージョン管理が厳格。アプリ開発向け
- GitLab Flow: 環境（Staging/Production）ごとにデプロイを制御したい場合に有効
-
保護ルール:
mainへの直コミットを禁止し、事故リスクを排除する - バージョン管理: ソースコードの特定地点を保存する
さて、ブランチ戦略で「テストが通らないとマージさせない」という設定が出てきましたが、この「テストの自動実行」を担うのがCI（継続的インテグレーション）です。
次回は、GitHubに標準搭載されている強力な自動化ツール 「GitHub Actions」 について解説します。