Git Flow

Git Flow とは

Git Flow は、Vincent Driessen が 2010 年に提唱したブランチ戦略で、main (原典の表記は master)、develop、feature、release、hotfix の 5 種類のブランチを使い分ける。リリースサイクルが明確なプロジェクト (モバイルアプリ、パッケージソフトウェア) に適している。

ブランチ構成

ブランチ構成を図で示す。

main ─────────────────────────────────── (本番リリース)
  │                              ↑
  └── develop ──────────────── release/1.0 ──→ main
        │         ↑                ↑
        └── feature/auth ──┘       │
        └── feature/cart ──┘       │
                                   │
  main ── hotfix/fix-login ────────┘──→ main + develop

ブランチ	寿命	用途
main	永続	本番リリース済みのコード
develop	永続	次のリリースの開発ベース
feature/*	短命	機能開発 (develop から分岐)
release/*	短命	リリース準備 (develop から分岐)
hotfix/*	短命	本番の緊急修正 (main から分岐)

ワークフロー

1. develop から feature/add-auth を作成
2. 機能を開発し、develop にマージ
3. リリース準備: develop から release/1.0 を作成
4. バグ修正を release/1.0 で行い、main と develop にマージ
5. main にタグ (v1.0.0) を付けてリリース
6. 本番バグ: main から hotfix/fix-login を作成し、main と develop にマージ

GitHub Flow との比較

GitHub Flow との主な違いを以下に比較する。

観点	Git Flow	GitHub Flow
ブランチ数	5 種類	2 種類 (main + feature)
複雑さ	高い	低い
リリース頻度	低い (計画的リリース)	高い (マージ = リリース)
適するケース	モバイルアプリ、パッケージ	Web アプリ、SaaS

Git Flow が不向きなケース

• CI/CD で頻繁にデプロイする Web アプリ → GitHub Flow の方がシンプル
• 小規模チーム (2〜3 人) → ブランチ管理のオーバーヘッドが大きい
• トランクベース開発を採用するチーム → develop ブランチが不要

作者の Vincent Driessen は 2010 年の原典に 2020 年 3 月の追記を加え、継続的デリバリーを行うチームには Git Flow を無理に当てはめず GitHub Flow のような単純なワークフローを採るよう勧めている。ただし撤回ではない。明示的にバージョンを持つソフトウェアや、複数バージョンを利用者の手元で並行サポートする場合は今も適合しうる、と条件を分けて述べている。

Git Flow を使うべきケース

• モバイルアプリ (App Store の審査があり、リリースが計画的)
• パッケージソフトウェア (バージョン管理が重要)
• 複数バージョンを同時にサポートする必要がある

Git Flow のブランチ運用例

Git Flow のブランチ運用例の例を示す。

# feature ブランチで開発
git checkout -b feature/order-validation develop
# ... 開発 ...
git checkout develop && git merge feature/order-validation

# リリース準備
git checkout -b release/1.2.0 develop
# ... バグ修正 ...
git checkout main && git merge release/1.2.0
git tag v1.2.0
git checkout develop && git merge release/1.2.0  # develop への戻しを忘れない

基礎から学ぶなら関連書籍が手がかりになる。