現場で学ぶ
Git Flow 導入事例
チーム規模やプロジェクトの特性によって、Git Flow の運用方法は変わります。 4つのシナリオで、導入のリアルを追体験しましょう。
5人チームの EC サイト開発
Project Profile
背景
創業2年目のスタートアップ。エンジニア3名、デザイナー1名、PM 1名の構成。 自社 EC サイトの新機能（クーポン機能・レコメンド機能）を並行開発する必要があった。 以前は main ブランチに直接 push していたが、デプロイ後に不具合が頻発し、Git Flow を導入。
導入前の課題
main に直接 push する運用で、以下の問題が起きていた。
Pain Points
- ✗ 金曜夕方の push でバグ混入 → 週末対応が常態化
- ✗ 「誰かが push したら自分のコードが壊れた」が頻発
- ✗ リリース範囲が不明確で、意図しない変更が本番に
- ✗ レビューなし → バグの早期発見ができない
Git Flow 導入で決めたルール
Team Rules
- ✓ feature ブランチは必ず PR 経由で develop にマージ
- ✓ PR には最低1人のレビュー承認を必須に
- ✓ release ブランチはスプリント最終日に作成
- ✓ hotfix は Slack で即共有 → 30分以内に対応開始
- ✓ feature → develop は Squash merge で履歴をクリーンに
導入後の効果
本番バグ 70% 減
PR レビューの義務化により、デプロイ前にバグを検出できるようになった。
リリース予測可能に
release ブランチで「何がリリースされるか」が明確になり、PM が安心してスケジュールを組めるように。
20人チームのモバイルアプリ開発
Project Profile
なぜ Git Flow がフィットしたか
モバイルアプリは App Store / Google Play の審査があるため、「いつでもデプロイ」ができない。 release ブランチで QA → 審査提出 → 承認待ちの期間を管理しつつ、 develop では次バージョンの開発を進められる Git Flow がぴったりだった。
審査中の hotfix 問題
v2.3.0 の審査待ち中に、v2.2.0 で決済エラーが発覚。 main (= v2.2.0) から hotfix を切り、緊急リリース (v2.2.1) を審査に出した。
main v2.2.0 ─── v2.2.1 (hotfix)
release/2.3.0 QA中 → 審査提出待ち
develop v2.4.0 の機能開発中
feature/* 3チームが並行開発中学び: Git Flow なら「審査中のリリース」「本番の緊急修正」「次バージョンの開発」を 3本のブランチで同時に管理できる。これは GitHub Flow では難しい。
feature フラグとの併用
大きな機能（チャット機能）は完成まで3スプリントかかるため、 feature フラグで非表示にしたまま develop にマージし、 完成後にフラグを有効化する運用に。
メリット
長寿命 feature ブランチによるコンフリクト地獄を回避。 develop との差分が小さいうちにマージするので、統合リスクが激減した。
BtoB SaaS の並行バージョン管理
Project Profile
課題: 顧客ごとにバージョンが違う
エンタープライズ顧客は移行スケジュールが異なるため、v3.x / v4.x / v5.x を並行サポートする必要があった。
Git Flow をベースに、サポートブランチ (support/v3.x, support/v4.x) を追加して運用。
main 最新の安定版 (v5.2.0)
develop v5.3.0 の開発中
feature/* 新機能開発
release/5.3.0 次回リリース準備
# Git Flow 標準にはない「サポートブランチ」
support/v4.x v4 系のセキュリティパッチ用
support/v3.x v3 系の重大バグ修正のみ
# 例: v4 系に hotfix を当てる場合
git checkout -b hotfix/v4-security support/v4.x
# 修正後
git checkout support/v4.x
git merge --no-ff hotfix/v4-security
git tag v4.8.3運用のポイント
セキュリティパッチは support/v3.x → support/v4.x → main の順にチェリーピックで適用。 機能追加は最新バージョンのみ。旧バージョンへのバックポートは厳格にセキュリティと重大バグに限定した。 これにより、50人の開発チームでも混乱なく3バージョンを維持できている。
Git Flow からの卒業 — Web アプリの場合
Project Profile
Git Flow が合わなくなった理由
CI/CD パイプラインが整備され、テストカバレッジも 90% を超えた。 1日に何度もデプロイしたいのに、release ブランチの作成・QA・マージが「儀式」になっていた。 develop と main の差分がほぼゼロの状態が続き、2本のブランチを維持する意味が薄れた。
GitHub Flow に移行
develop ブランチを廃止。main から直接 feature を切り、PR マージ後に自動デプロイする構成に変更。
Before (Git Flow):
main ← release ← develop ← feature
4ブランチ / 手動リリース / 月2回デプロイ
After (GitHub Flow):
main ← feature
2ブランチ / 自動デプロイ / 1日5回デプロイ移行で気をつけたこと
Migration Checklist
- ✓ テストカバレッジ 80% 以上を確認
- ✓ CI/CD が main マージで自動デプロイする構成に
- ✓ feature フラグの仕組みを先に導入
- ✓ ロールバック手順を文書化
- ✓ 1ヶ月の並行運用期間で慣らし
重要: この事例は「Git Flow がダメ」という話ではありません。 プロジェクトの成熟度や要件が変われば、最適なブランチ戦略も変わるということです。 Git Flow で学んだ「ブランチの役割を明確にする」という考え方は、どの戦略に移行しても活きます。
あなたのチームに合うか判断する
Quick Decision Tree
以下の質問に Yes / No で答えてみてください。
Q1. リリースに承認プロセスや審査がある？
Yes → Git Flow が有力候補
No → Q2 へ
Q2. 複数バージョンを並行サポートする？
Yes → Git Flow + support ブランチ (Case 03)
No → Q3 へ
Q3. CI/CD が整備され、テストカバレッジが高い？
Yes → GitHub Flow / Trunk-Based を検討
No → Git Flow で段階的に整備
Q4. チームが5人以上 or リリース頻度が月2回以下？
Yes → Git Flow が安定
No → GitHub Flow で十分な可能性