ブランチ戦略
Git Flow・GitHub Flowなど代表的なブランチ運用モデルと、チームに合った戦略の選び方を学ぶ
なぜブランチ戦略が必要なのか
複数人が同時に開発を進める中で、「いつ・どこで・何を統合するか」のルールがないと、 誰かの未完成な変更が他の人の作業やリリースに混ざってしまいます。 ブランチ戦略は、この統合のタイミングと方法をチームで合意しておく仕組みです。
GitHub Flow / トランクベース開発（現代の主流）
継続的デリバリーを実践する現代のWebサービス開発では、mainブランチを常にリリース可能な状態に保ち、 そこから短命なフィーチャーブランチを切って作業し、レビューを経てすぐにmainへ統合するGitHub Flowやトランクベース開発が広く採用されています。
GitHub Flowの基本的な流れ:
1. main から feature/add-checkout のようなブランチを作成する
2. そのブランチで作業し、こまめにコミットする
3. 作業がまとまったらプルリクエストを作成する
4. レビューとCIのチェックが通ったらmainにマージする
5. mainへのマージをトリガーに自動でデプロイする（継続的デリバリー）ポイント
ブランチの寿命が短いほど、他のブランチとのコンフリクトが起きにくくなります。 「大きな機能を長期間別ブランチで開発し続ける」よりも、 フィーチャーフラグ等を使って小さく分割し頻繁に統合するほうが、現代の実務では好まれます。
Git Flow（伝統的なモデル）
Git Flowは、 main（本番）・develop（開発統合）・feature・release・hotfixという 複数の役割を持つブランチを使い分ける、比較的重厚なモデルです。
Git Flowの主なブランチ:
main - 本番リリース済みの状態を表す
develop - 次のリリースに向けた開発の統合先
feature - developから分岐し、個々の機能を開発する
release - リリース準備（バージョン確定・最終調整）を行う
hotfix - 本番で見つかった緊急バグをmainに直接適用し、developにもマージバックするGit Flowが向くケース
- • 複数バージョンを同時にサポートするパッケージソフトウェア
- • リリースサイクルが数週間〜数ヶ月と長い開発
- • リリース前に明示的な検証フェーズが必要な業務系システム
向かないケース
- • 1日に何度もデプロイするWebサービス
- • developとmainの二重管理がコンフリクトの温床になりやすい小〜中規模チーム
Git Flowは決して「古くて使うべきでない」モデルではありませんが、 高頻度デプロイを前提とする現代のSaaS開発では、ブランチの管理コストが メリットを上回ってしまうことが多く、GitHub Flowやトランクベース開発が選ばれる傾向にあります。
チームに合った戦略の選び方
デプロイ頻度を確認する
1日に何度もデプロイするなら、GitHub Flow / トランクベース開発が適している
複数バージョンの同時サポートが必要か確認する
古いバージョンにもパッチを当て続ける必要があるなら、releaseブランチの管理が必要になる
CI/CDの成熟度を確認する
自動テスト・自動デプロイが整っているほど、短命なブランチでの頻繁な統合がしやすくなる
ポイント
- • 現代のWebサービス開発では、mainを常にリリース可能に保つGitHub Flow / トランクベース開発が主流
- • Git Flowはリリースサイクルが長い・複数バージョンを同時サポートする場面で有効な選択肢
- • ブランチの寿命が短いほどコンフリクトが起きにくい
- • デプロイ頻度・複数バージョンサポートの要否・CI/CDの成熟度をもとに戦略を選ぶ
確認クイズ
1 / 3GitHub Flowの基本的な考え方として正しいものはどれか？