IT 技書の森

Git Flow

feature、develop、release、hotfix、main の 5 種類のブランチで開発を管理するブランチ戦略

Gitブランチ戦略

Git Flow とは

Git Flow は、Vincent Driessen が 2010 年に提唱したブランチ戦略で、main、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 との比較

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

Git Flow が不向きなケース

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

Git Flow の作者自身が 2020 年に「Web アプリには Git Flow は複雑すぎる。GitHub Flow を使うべき」と述べている。

Git Flow を使うべきケース

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

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

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

関連用語