Branching Strategy
チーム開発を支える
Git Flow モデル
Git Flow は Vincent Driessen が2010年に提唱したブランチ戦略。 リリース管理と並行開発を両立する、最も普及したワークフローのひとつです。
// What is Git Flow
Git Flow とは
明確なブランチ役割
main / develop / feature / release / hotfix の5種類のブランチを使い、 それぞれの目的と寿命を明確に定義します。
並行開発
複数の feature ブランチで同時に開発を進め、 develop ブランチに統合することで衝突を最小限に抑えます。
安定したリリース
release ブランチでリリース準備を行い、 main ブランチは常にプロダクション品質を保ちます。
緊急対応
hotfix ブランチにより、本番環境の緊急バグを 通常の開発フローを止めることなく修正できます。
Branch Overview
main
プロダクション。タグ付きリリースのみ。
hotfix/*
本番の緊急修正。main から分岐 → main + develop へマージ。
release/*
リリース準備。develop から分岐 → main + develop へマージ。
develop
次期リリースの統合ブランチ。常に最新の開発状態。
feature/*
新機能開発。develop から分岐 → develop へマージ。
// Why Git Flow
Git Flow を採用する理由
本番の安全性
main ブランチに直接コミットしないルールにより、 プロダクション環境の安定性を担保します。
チームスケーラビリティ
各開発者が独立した feature ブランチで作業するため、 チーム規模が大きくなっても混乱しにくい構造です。
計画的リリース
リリースサイクルが明確で、QA やステージング環境での テストを組み込みやすいプロセスです。
// When to Use
適用が向いているケース
Best Fit
✓ 向いている
- • 定期リリースサイクルがある
- • 複数バージョンの並行サポート
- • チーム規模が5名以上
- • QA / ステージング環境がある
- • リリース承認プロセスが必要
✗ 向いていない
- • 継続的デプロイ (CD) 環境
- • 小規模チーム (1-3名)
- • マイクロサービスの個別デプロイ
- • trunk-based が合う高速リリース