ブランチ戦略を理解しよう

ストーリー

チームの朝会で、リーダーがホワイトボードにブランチの図を描き始めた。

「来週から新機能の開発を並行で進める。ブランチ戦略を確認しておこう」

あなたはL0でブランチの基本は学んだが、「戦略」と言われると心もとない。

佐藤先輩が小声で言った。

「ブランチの作り方は知ってるだろ？ここからは、 いつ・どこから・何のためにブランチを切るか -- その"戦略"を学ぶんだ」

ブランチ戦略とは

ブランチ戦略とは、チームでGitを使う際の「ブランチの運用ルール」です。

いつブランチを作るか
どこからブランチを切るか
どうやってマージするか
リリースはどのブランチから行うか

なぜ戦略が必要か

戦略がないと...
├── Aさんが main に直接コミット → ビルドが壊れる
├── Bさんの作業中のコードが混入 → テストが通らない
├── 本番リリースのタイミングが不明 → デプロイ事故
└── 誰が何をしているか不明 → チーム混乱

Git Flow

最も有名で体系的なブランチ戦略です。大規模プロジェクトに適しています。

ブランチの種類

ブランチ	役割	寿命
`main`	本番リリース済みコード	永続
`develop`	開発の統合ブランチ	永続
`feature/*`	新機能の開発	一時的
`release/*`	リリース準備	一時的
`hotfix/*`	本番の緊急修正	一時的

流れ

main ────●──────────────●──────●── (本番)
          \            / \    /
develop ───●──●──●──●──●───●──●── (開発統合)
              \  /          |
feature/A ─────●            |
                     hotfix/bug ─●

develop から feature/xxx ブランチを切る
開発完了後、feature/xxx を develop にマージ
リリース準備で develop から release/x.x を切る
テスト完了後、release/x.x を main と develop にマージ
緊急修正は main から hotfix/xxx を切り、修正後に両方にマージ

向いているプロジェクト

リリースサイクルが決まっている
複数バージョンを保守する必要がある
チーム規模が大きい（10人以上）

GitHub Flow

シンプルさを重視した戦略です。多くのWebサービス開発で採用されています。

ルール（6つだけ）

main ブランチは常にデプロイ可能
新しい作業は main から説明的な名前のブランチを作成
そのブランチにコミットを積む
Pull Request を開いてレビューを依頼
レビュー承認後、main にマージ
マージ後すぐにデプロイ

流れ

main ────●─────────●───●─────── (常にデプロイ可能)
          \       /     \
feature ───●──●──●       \
                    fix ──●──●

向いているプロジェクト

継続的デプロイ（CD）を実践している
チーム規模が小〜中規模
Webアプリケーション開発

Feature Branch Workflow

最もシンプルなブランチ戦略です。

ルール

各機能（feature）ごとにブランチを作成
main ブランチには直接コミットしない
Pull Request 経由でマージ

ブランチ名の命名規則

bash

# 機能追加
feature/user-authentication
feature/shopping-cart

# バグ修正
fix/login-error
fix/payment-calculation

# 改善
improve/performance-optimization
improve/code-refactoring

# ドキュメント
docs/api-documentation

# チケット番号付き（推奨）
feature/PROJ-123-user-authentication
fix/PROJ-456-login-error

戦略の選び方

基準	Git Flow	GitHub Flow	Feature Branch
チーム規模	大（10+）	小〜中	小〜中
リリース頻度	定期的	常時	常時
複雑さ	高い	低い	低い
学習コスト	高い	低い	低い
CI/CD	推奨	必須	推奨

初学者への推奨: まずは GitHub Flow を使いましょう。シンプルで理解しやすく、最もよく使われている戦略です。

まとめ

ポイント	内容
ブランチ戦略	チームでの Git 運用ルール
Git Flow	体系的だが複雑。大規模プロジェクト向き
GitHub Flow	シンプルで実用的。Web開発の定番
Feature Branch	最もシンプル。小規模チーム向き
命名規則	`feature/`, `fix/`, `docs/` などの接頭辞を使う

チェックリスト

ブランチ戦略の必要性を説明できる
Git Flow の5種類のブランチを説明できる
GitHub Flow の6つのルールを理解した
プロジェクトに合った戦略を選べる
ブランチの命名規則を守れる

次のステップへ

ブランチ戦略の全体像をつかみましたね。

次のセクションでは、ブランチを統合する2つの方法「マージ」と「リベース」の違いと使い分けを学びます。

推定読了時間: 20分