Git Flowとtrunk-based developmentの違い

開発ツール

Gitブランチ運用には、長年Git Flowが使われてきましたが、近年はtrunk-based development（TBD）への移行が進んでいます。本記事では、両者の違いと選び方を解説します。

Git Flowとは

main・develop・feature・release・hotfixなど、用途別のブランチを使い分ける運用パターン。リリース管理が明確で、複雑なプロダクトに向いていました。

trunk-based developmentとは

長期ブランチを作らず、mainに対して短命の小さなブランチを頻繁にマージしていく方法。フィーチャーフラグや継続的デプロイと相性が良いです。

比較

  • ブランチ数：Git Flow多、TBD少
  • マージ頻度：Git Flow少、TBD高頻度（1日数回も）
  • リリース管理：Git Flow=ブランチで明示、TBD=フィーチャーフラグ
  • コンフリクト：Git Flow発生しやすい、TBD少
  • 運用負荷：Git Flow高、TBD軽い

typical Git Flowの構造

main      ────●────●────●  (本番)
             /     /    /
release/ ──●─────●     /
              /    \  /
develop ─●──●──●──●──●  (開発統合)
        / \    \
feature/x feature/y

trunk-basedの構造

main ─●──●──●──●──●──●──●──●  (常にデプロイ可能)
       \  \  \  \  \  \  \
       short-lived feature branches

選び方の指針

  • 継続的デプロイ・SaaS開発：trunk-based
  • 明確なリリース版数管理が必要：Git Flow
  • 少人数・速いリリースサイクル：trunk-based
  • 大規模・複数バージョン並行運用：Git Flow

TBD成功のコツ

  • 1ブランチを2日以内に統合
  • フィーチャーフラグで未完成機能を本番に隠す
  • CIで自動テスト・自動マージを徹底
  • main保護＋PR必須＋レビュー文化

GitHub Flow（中間案）

main + 短命feature + PRレビュー、というシンプルなフローはGitHub Flowと呼ばれ、Web開発で広く使われています。多くのチームはこれを起点に、必要があればtrunk-basedへ進化させます。

まとめ

Git Flowは「明確だが重い」、trunk-basedは「速いが規律が必要」。SaaSや継続デプロイならTBD、複数バージョン並行運用ならGit Flowを軸に、現実的にはGitHub Flowをベースに改良するチームが多いです。