コラム / 開発/エンジニアリング /
Git ブランチ戦略の現実解 ─ GitFlow が破綻する条件と5/20/50人規模での選び方
教科書の通り名で語るのを止めて、リリース頻度・チーム規模・テスト基盤・hotfix発生率の4変数で決める
📖 約8分 / 公開日: 2026/05/31
5人のスタートアップが GitFlow を導入して半年で破綻する光景を、これまで何度も見てきました。develop ブランチが2週間更新されない、release ブランチが先月のまま残っている、hotfix がどこから生やすべきか毎回議論になる。原典のVincent Driessen の2010年の記事を読み返すと、これは月次リリースを前提とした重厚な戦略です。週に何度もデプロイするチームの実態と噛み合わない。
ブランチ戦略の選択は、単なる慣習の問題ではありません。CI/CDの実行コスト、リリース頻度、hotfix発生率、コードレビューの所要時間、コンフリクトの解消時間が全部影響を受けます。月10万円のGitHub Actions利用料が30万円になるか、リリースが週次か日次かが分かれ目になるか、ここが決まる場所です。
GitFlow を機能させる条件はかなり厳しいです。リリースが月次以下、本番ホットフィックスが月1件以下、ステージング環境が独立して維持できる、リリースマネージャーが専任、この4つが揃って初めて元論文通りに回ります。SaaSをCDで日次デプロイしている開発組織には合いません。Driessen 自身が2020年の追記で「Web アプリには prescribe しない、Git Flow は古い」と書いている事実は、もっと知られていいはずです。
代わりに5〜20人規模で勧められるのが GitHub Flow です。main から直接 feature ブランチを切り、PR を出してマージ、main を常時デプロイ可能に保つ。シンプルさが正義です。ただし、これが機能するためにも前提があります。E2Eを含むテストが10分以内に終わる、feature flag で未完成機能を本番へ出せる、ロールバックが3分以内に可能、この3点です。テストが30分かかるならPRが詰まり、結局GitFlow的な滞留が再発します。
trunk-based development はさらに踏み込んで、feature ブランチをそもそも作らない、もしくは寿命24時間以内に絞る戦略です。Google や Meta が採用していると喧伝されますが、その実態は monorepo に数千人がコミットする世界の話で、20人の日本のSaaS開発チームがそのまま真似ても得るものは少ない。導入するなら、PRレビューを「マージ後に行う」覚悟、feature flag の徹底、そしてCIのテスト粒度の細分化が必須です。準備なしに導入したチームは、main の壊滅と切り戻し作業に追われます。
規模別の現実解はこう整理しています。1〜5人なら GitHub Flow に近い形で main + feature の二層。release ブランチは不要で、タグでリリースを記録するだけで十分。6〜20人なら GitHub Flow をベースに、必要に応じて release/x.y ブランチを「リリース当日だけ」生やしてタグ付けと同時に削除する運用。develop ブランチを常設する必然性は薄い。20人以上、特に複数チームが並走する規模では、trunk-based に近づけつつ、各チームの責務領域を CODEOWNERS で明確化し、feature flag を運用ルール化する。LaunchDarkly が高いなら Unleash や Flagsmith のセルフホスト構成で十分実用になります。
feature ブランチの寿命は、72時間を一つの基準にしています。これを超えると、ほぼ確実にコンフリクトの解消コストが急増します。長く生かしたい理由がある場合、それはたいてい「PRが大きすぎる」「レビュアーが捕まらない」「飛び込み割り込みでブロック」のいずれかで、ブランチ戦略では解けません。PRを300行以下に分割するルールの方が、よほど効きます。GitHubのPR statisticsを見ると、レビュー所要時間は変更行数に対して非線形に伸びる傾向があり、500行を超えると一気にスタックします。
hotfix の運用も悩みどころです。GitFlow のように hotfix ブランチを毎回切るのは過剰です。main から直接 fix の PR を立て、マージしたコミットに v1.4.2 のタグを打ち、必要なら過去のリリースタグからチェリーピックで対応する。これでほとんどのケースは回ります。複数の旧バージョンを並行サポートするプロダクト、たとえばオンプレで顧客ごとにバージョンがズレているような場合は別で、ここは LTS ブランチを長期維持する必要があります。
monorepo か polyrepo かでブランチ戦略の意味合いも変わります。monorepo であれば trunk-based の親和性が高いが、ビルド対象の選別、つまり Changed files に応じた CI 実行のスコープ絞り込みが不可欠です。Nx・Turborepo・Bazel のいずれかで affected detection を入れていないと、変更1行で1時間のCIが走る悪夢が再現します。polyrepo の場合は逆に、リポジトリごとに戦略を変えてよい。フロントは GitHub Flow、決済系のミドルウェアだけ GitFlow という併用は実務上ありえます。
CI/CD との結合も切り離せません。trunk-based の本質は「main を常に green に保つ」ことで、これを支えるのは事前の pre-merge CI ではなく、post-merge での即時カナリア配信とロールバック自動化です。Argo Rollouts や Flagger を入れて段階的にトラフィックを流す、Datadog のエラーレート閾値でロールバックを即発火する、こういう仕組みがないと trunk-based は単なる「無謀」になります。
CI/CDのコスト面も無視できません。GitHub Actions の Linux runner（2-core）は分あたり0.008ドル、4-coreなら0.016ドル、8-coreなら0.032ドル。ブランチ戦略を変えてPR数や実行頻度が増えれば、月額利用料は線形以上に伸びます。実例として、20人チームが GitFlow から trunk-based へ移行した結果、PRごとの CI 実行回数が増えて月額が12万円から28万円に増えたケースがありました。affected detection を入れて該当パッケージだけ走らせる構成に直し、最終的に月額9万円台へ落ち着きました。戦略変更はCI設計のリファクタとセットで考えるべきです。
リリースタグ運用も整理しておきます。SemVer（MAJOR.MINOR.PATCH）で v1.4.2 のように打ち、CHANGELOG.md を Keep a Changelog 形式で書き、GitHub Releases にビルド成果物を添付する。これだけでも release ブランチを切る必要はほぼなくなります。pre-release タグとして v1.5.0-rc.1 のように rc を切ればステージング検証もカバーできる。タグから過去のソースを即座にチェックアウトできる、これがブランチ常設より遥かに安全な状態です。
よく聞かれる反対意見にも触れておきます。GitFlow を擁護する派の主張は「リリースの可視性が高い、release ブランチで安定化期間を取れる」というもので、これは確かに正しい。月次リリースの大規模パッケージ製品やオンプレ製品なら GitFlow が優位です。trunk-based を擁護する派は「ブランチがないほうが結局速い」と言うが、これも前提が揃った組織でのみ正しい。万能の戦略は存在しない、リリース頻度・チーム規模・テスト基盤の成熟度・hotfix発生率という4変数で、機械的に決まる選択肢です。教科書の通り名で語るのを止めて、自分のチームの数字を見るところから始めてください。
ブランチ戦略の選択は、単なる慣習の問題ではありません。CI/CDの実行コスト、リリース頻度、hotfix発生率、コードレビューの所要時間、コンフリクトの解消時間が全部影響を受けます。月10万円のGitHub Actions利用料が30万円になるか、リリースが週次か日次かが分かれ目になるか、ここが決まる場所です。
GitFlow を機能させる条件はかなり厳しいです。リリースが月次以下、本番ホットフィックスが月1件以下、ステージング環境が独立して維持できる、リリースマネージャーが専任、この4つが揃って初めて元論文通りに回ります。SaaSをCDで日次デプロイしている開発組織には合いません。Driessen 自身が2020年の追記で「Web アプリには prescribe しない、Git Flow は古い」と書いている事実は、もっと知られていいはずです。
代わりに5〜20人規模で勧められるのが GitHub Flow です。main から直接 feature ブランチを切り、PR を出してマージ、main を常時デプロイ可能に保つ。シンプルさが正義です。ただし、これが機能するためにも前提があります。E2Eを含むテストが10分以内に終わる、feature flag で未完成機能を本番へ出せる、ロールバックが3分以内に可能、この3点です。テストが30分かかるならPRが詰まり、結局GitFlow的な滞留が再発します。
trunk-based development はさらに踏み込んで、feature ブランチをそもそも作らない、もしくは寿命24時間以内に絞る戦略です。Google や Meta が採用していると喧伝されますが、その実態は monorepo に数千人がコミットする世界の話で、20人の日本のSaaS開発チームがそのまま真似ても得るものは少ない。導入するなら、PRレビューを「マージ後に行う」覚悟、feature flag の徹底、そしてCIのテスト粒度の細分化が必須です。準備なしに導入したチームは、main の壊滅と切り戻し作業に追われます。
規模別の現実解はこう整理しています。1〜5人なら GitHub Flow に近い形で main + feature の二層。release ブランチは不要で、タグでリリースを記録するだけで十分。6〜20人なら GitHub Flow をベースに、必要に応じて release/x.y ブランチを「リリース当日だけ」生やしてタグ付けと同時に削除する運用。develop ブランチを常設する必然性は薄い。20人以上、特に複数チームが並走する規模では、trunk-based に近づけつつ、各チームの責務領域を CODEOWNERS で明確化し、feature flag を運用ルール化する。LaunchDarkly が高いなら Unleash や Flagsmith のセルフホスト構成で十分実用になります。
feature ブランチの寿命は、72時間を一つの基準にしています。これを超えると、ほぼ確実にコンフリクトの解消コストが急増します。長く生かしたい理由がある場合、それはたいてい「PRが大きすぎる」「レビュアーが捕まらない」「飛び込み割り込みでブロック」のいずれかで、ブランチ戦略では解けません。PRを300行以下に分割するルールの方が、よほど効きます。GitHubのPR statisticsを見ると、レビュー所要時間は変更行数に対して非線形に伸びる傾向があり、500行を超えると一気にスタックします。
hotfix の運用も悩みどころです。GitFlow のように hotfix ブランチを毎回切るのは過剰です。main から直接 fix の PR を立て、マージしたコミットに v1.4.2 のタグを打ち、必要なら過去のリリースタグからチェリーピックで対応する。これでほとんどのケースは回ります。複数の旧バージョンを並行サポートするプロダクト、たとえばオンプレで顧客ごとにバージョンがズレているような場合は別で、ここは LTS ブランチを長期維持する必要があります。
monorepo か polyrepo かでブランチ戦略の意味合いも変わります。monorepo であれば trunk-based の親和性が高いが、ビルド対象の選別、つまり Changed files に応じた CI 実行のスコープ絞り込みが不可欠です。Nx・Turborepo・Bazel のいずれかで affected detection を入れていないと、変更1行で1時間のCIが走る悪夢が再現します。polyrepo の場合は逆に、リポジトリごとに戦略を変えてよい。フロントは GitHub Flow、決済系のミドルウェアだけ GitFlow という併用は実務上ありえます。
CI/CD との結合も切り離せません。trunk-based の本質は「main を常に green に保つ」ことで、これを支えるのは事前の pre-merge CI ではなく、post-merge での即時カナリア配信とロールバック自動化です。Argo Rollouts や Flagger を入れて段階的にトラフィックを流す、Datadog のエラーレート閾値でロールバックを即発火する、こういう仕組みがないと trunk-based は単なる「無謀」になります。
CI/CDのコスト面も無視できません。GitHub Actions の Linux runner（2-core）は分あたり0.008ドル、4-coreなら0.016ドル、8-coreなら0.032ドル。ブランチ戦略を変えてPR数や実行頻度が増えれば、月額利用料は線形以上に伸びます。実例として、20人チームが GitFlow から trunk-based へ移行した結果、PRごとの CI 実行回数が増えて月額が12万円から28万円に増えたケースがありました。affected detection を入れて該当パッケージだけ走らせる構成に直し、最終的に月額9万円台へ落ち着きました。戦略変更はCI設計のリファクタとセットで考えるべきです。
リリースタグ運用も整理しておきます。SemVer（MAJOR.MINOR.PATCH）で v1.4.2 のように打ち、CHANGELOG.md を Keep a Changelog 形式で書き、GitHub Releases にビルド成果物を添付する。これだけでも release ブランチを切る必要はほぼなくなります。pre-release タグとして v1.5.0-rc.1 のように rc を切ればステージング検証もカバーできる。タグから過去のソースを即座にチェックアウトできる、これがブランチ常設より遥かに安全な状態です。
よく聞かれる反対意見にも触れておきます。GitFlow を擁護する派の主張は「リリースの可視性が高い、release ブランチで安定化期間を取れる」というもので、これは確かに正しい。月次リリースの大規模パッケージ製品やオンプレ製品なら GitFlow が優位です。trunk-based を擁護する派は「ブランチがないほうが結局速い」と言うが、これも前提が揃った組織でのみ正しい。万能の戦略は存在しない、リリース頻度・チーム規模・テスト基盤の成熟度・hotfix発生率という4変数で、機械的に決まる選択肢です。教科書の通り名で語るのを止めて、自分のチームの数字を見るところから始めてください。