ブランチ戦略は「流行りに乗る」対象ではなく、デプロイ頻度とリリース形態から逆算して選ぶ設計判断です。海外で確立した4つの型を、日本のエンタープライズ現場の制約に翻訳して整理します。
「どのブランチ戦略が正解か」という問いには、単独の正解がありません。デプロイの頻度、リリースの形態（継続デプロイなのか、バージョンを固定して出荷するのか）、そしてレビューや承認にまつわる組織的な制約によって、適した型は変わります。本記事では海外で確立した4つの型を、それぞれが暗黙に前提としている運用条件まで含めて整理し、日本のSIer・エンタープライズの現場でどう選ぶかを実務目線でまとめます。
014つの型の全体像
まず登場人物を揃えます。歴史的な順に、Git Flow・GitHub Flow・GitLab Flow・Trunk-Based Development（以下 TBD）の4つです。それぞれ「ブランチをどれだけ持つか」「どこがデプロイの起点か」が異なります。
- Git Flow：
main・develop・feature/*・release/*・hotfix/*という複数の長命ブランチを持つ重厚な型。定期リリース・複数バージョン並行保守の時代に広く使われました。 - GitHub Flow：
mainと短命なfeatureブランチだけ。PRでレビューし、マージしたら即デプロイする継続デプロイ向きの軽量な型です。 - GitLab Flow：GitHub Flowに環境ブランチ（
staging→productionなど）やリリースブランチ（v1/v2）を足して、デプロイ制御やバージョン保守を織り込んだ型です。 - Trunk-Based Development：全員が
main（trunk）へ1日1回以上マージする。ブランチは持っても寿命が数時間〜1日。未完成の機能はfeature flagで隠します。
この4つは「進化の系譜」ではありますが、後発が常に優れているわけではありません。組織の制約次第で、あえて重厚な型を選ぶ合理性も残ります。
02Git Flow — 重厚さが要る前提
Git Flowは、Vincent Driessen氏が2010年に提唱した型です。developを統合ブランチとし、release/*でリリース準備、hotfix/*で緊急修正、という役割分担が明確なのが特徴です。この構造が力を発揮するのは、デプロイが自動化されておらず、リリースが「日付を決めて出す」イベントである場合です。パッケージソフト、オンプレミス製品、複数バージョンを同時に保守するプロダクトなどが典型です。
一方で、継続デプロイを志向する現場では、developとmainの二重管理やlong-livedなブランチ間のマージが摩擦を生みます。ブランチが長生きするほど、マージ時のコンフリクトと「統合フェーズ」の痛みが増える——これは後述するDORAの指摘とも一致します。Git Flowは悪い設計ではなく、前提とするリリース形態が違うのです。自社のリリースがイベント型なら、いまでも合理的な選択肢です。
03GitHub Flow — mainとfeatureだけ
GitHub Flowは、GitHub社が自社の運用として確立した軽量な型です。公式ドキュメントでは、(1)ブランチを作る、(2)変更する、(3)Pull Requestを作る、(4)レビュー指摘に対応する、(5)マージする、(6)ブランチを削除する、という6ステップとして定義されています（GitHub Docs: GitHub flow）。長命ブランチはmainただ一本です。
この型の暗黙の前提は「mainは常にデプロイ可能な状態を保つ」ことです。マージ即デプロイ、あるいはマージ後すぐにパイプラインが本番へ運ぶ運用と噛み合います。SaaS・Web系のように、いつでも本番を差し替えられるプロダクトに向きます。
mainのコミットを、パイプラインがstaging→productionへ順に昇格させる——この分離を最初に握っておくと、後段のGitLab FlowやTBDへも素直に接続できます。環境昇格の設計は環境昇格（Promotion）の設計で詳しく扱います。04GitLab Flow — 環境/リリースブランチを足す
GitLab Flowは、GitHub Flowの軽さを保ちつつ、実運用で必要になりがちな2つの拡張を明文化した型です。GitLab公式の説明を引くと、次の2系統があります（GitLab: What is GitLab Flow?）。
- 環境ブランチ（environment branches）：
main→staging→productionのように環境に対応するブランチを置き、コミットを下流へ流す。公式は「必要なだけ前段ブランチを追加できる（from main to test, from test to acceptance, and from acceptance to production）」と述べ、あらゆる環境でコードが検証されるよう、コミットは下流へ流れると説明しています。ブランチへのマージ＝その環境へのデプロイ、という対応が取れるのが利点です。 - リリースブランチ（release branches）：公開APIなど複数バージョンを保守する場合に
v1/v2を個別に維持する。重要なのがupstream firstポリシーで、バグ修正はまずmainへ入れ、そこからリリースブランチへcherry-pickします。GitLabはこれをGoogleやRed Hatも採る方針だと紹介しています。
環境ブランチは、承認ゲートや「本番へ出す前に必ずステージングで止める」という統制をブランチで可視化したい現場に馴染みます。GitHub Flowが「パイプラインで環境を分ける」思想なのに対し、GitLab Flowは「ブランチにも環境の意味を持たせる」中間解、と捉えると使い分けが見えてきます。
05Trunk-Based Development — 短命ブランチとfeature flag
TBDは、全員が単一のtrunk（main）へ高頻度でマージする型です。ブランチを使う場合も寿命は数時間〜1日程度に抑え、未完成の機能はmainにマージした上でfeature flagで実行時に隠します。Atlassianはこれを「小さく頻繁な更新を中心のtrunkへマージするバージョン管理のプラクティス」と整理し、feature flagが別のfeatureブランチを作らずに本番コードへ直接コミットすることを可能にする、と説明しています（Atlassian: Trunk-based development）。
「未完成コードをmainに入れて大丈夫か」という不安が最初の壁ですが、ここを解くのがflagです。コードは統合するが振る舞いはOFFにしておく——これにより、マージを遅らせることなく、リリースのタイミングだけを分離できます。トグルの管理コスト、消し忘れ（flag debt）、テストの組み合わせ爆発といった運用の宿題は残るので、flagのライフサイクル（作成・展開・撤去）を最初に決めておくのが定石です。
06なぜDORAはTrunk-Basedを支持するのか
ブランチ戦略の議論で外せないのが、DORA（DevOps Research and Assessment）の継続的な調査です。DORAはtrunk-based developmentを、ソフトウェアデリバリのパフォーマンスを高める中核ケイパビリティのひとつとして挙げています。公式の定義では、成功要因を次の3点に集約しています（DORA: Trunk-based development）。
- アプリのコードリポジトリでアクティブなブランチを3本以下に保つ
- ブランチを1日1回以上trunkへマージする
- コードフリーズや統合フェーズを持たない
DORAは、この実践がデリバリのスピード・安定性・可用性を同時に押し上げると述べ、その根拠として2016年および2017年のState of DevOps Reportを引いています。加えて「trunk-based developmentは継続的インテグレーションに必須のプラクティス」とも位置づけています（DORA: Continuous delivery）。ポイントは、支持されているのは「ブランチ名の付け方」ではなくブランチを長生きさせないことだという点です。長命ブランチが減るほどマージイベントの複雑さが下がり、コードが常に最新に保たれる——因果はここにあります。
07SIer・エンタープライズでの現実的な選び方
「TBDが最も支持されている」と分かっても、日本のエンタープライズ現場には固有の制約があります。リリース承認の稟議、本番反映のメンテナンス枠、テスト工程の分業、監査で問われる「誰がいつ承認したか」の証跡——これらを無視して理想型を押し込むと、かえって運用が壊れます。現実的には、次の順で考えるのが実務的です。
- リリースがイベント型か、継続型か：日付固定の出荷・オンプレ納品・複数バージョン保守が主なら、Git Flowやリリースブランチ付きGitLab Flowが素直です。無理にTBD化しても稟議とかみ合いません。
- 環境ゲートを統制でどう見せるか：本番前に必ず止める承認ゲートを可視化したいなら、GitLab Flowの環境ブランチが監査説明と相性が良い。GitHub Flow＋パイプライン制御でも同じ統制は組めるので、「監査に説明しやすい形」で選びます。
- デプロイの自動化がどこまで進んでいるか：CI/CDが未整備な段階でTBDだけ導入しても、
mainが壊れるリスクが上がるだけです。自動テストとパイプラインの整備が先。順序を守ると失敗しません。 - チームのブランチ寿命を測る：型の名前より、まず「featureブランチが平均何日生きているか」を可視化する。長ければ、名前を変えずとも小さく刻む運用へ寄せるだけで効果が出ます。
結論として、多くのエンタープライズの落としどころは「GitHub Flowを土台に、必要な統制だけGitLab Flow的に足し、チームの成熟に応じてブランチ寿命をTBDへ近づける」という漸進です。いきなり最終形を目指すより、long-livedブランチを削り、feature flagとパイプライン昇格を段階的に整える方が、既存の承認プロセスを壊さずに移行できます。IaCのパイプライン設計と合わせて考えると全体像が締まります（IaCのCI/CDパイプライン設計）。
—まとめ
ブランチ戦略は、デプロイ頻度とリリース形態から逆算する設計判断です。Git Flowは定期リリース・複数バージョン保守に、GitHub Flowは継続デプロイに、GitLab Flowは環境・バージョン統制を足したい現場に、TBDは高頻度デリバリを狙うチームに向きます。DORAが一貫して支持するのは特定の名前ではなく「ブランチを長生きさせない」という原理でした。自社のリードタイムと承認プロセスを測ったうえで、既存運用を止めない漸進的な移行を設計する——これがSIer・エンタープライズにとっての現実解です。具体の設計はお問い合わせからご相談ください。