LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

代表的な3つのブランチ戦略：GitFlow・GitHub Flow・トランクベース開発

トランクベース開発とは、開発者が単一の共有ブランチ（trunkまたはmain）に対して作業を小さな単位に分割し、1日に1回以上マージし続けるソースコード管理の方式を指します^*1。長期間残る機能ブランチを作らず、マージの衝突が積み重なる前に統合を繰り返す点が特徴です。

ブランチ戦略には複数の系統があります。それぞれ前提とする開発体制・リリース頻度が異なるため、優劣ではなく適用条件で整理する必要があります。

GitFlow：バージョン管理されたリリースを前提とする戦略

GitFlowは、Vincent Driessen氏が2010年に提唱したブランチモデルです^*2。master（本番相当）とdevelop（開発の最新状態）という2つの永続ブランチに加え、feature・release・hotfixという用途別の補助ブランチを組み合わせます。

提唱者本人が2020年の追記で振り返っているとおり、GitFlowは「複数バージョンを並行サポートする必要があり、継続的デリバリーではなく明確にバージョン管理されたソフトウェア」を想定した設計です^*2。パッケージソフトやオンプレミス製品のように、リリースバージョンを区切って配布する開発には適しますが、Webサービスのように頻繁にデプロイする体制ではブランチの本数と統合作業が増えやすくなります。

GitHub Flow：プルリクエスト中心の軽量な戦略

GitHub Flowは、GitHubが自社のドキュメント・サイトポリシー運用などで使っている軽量なワークフローです^*3。mainブランチから機能ごとにブランチを作成し、プルリクエストでレビューを受けたうえでmainにマージする流れを基本とします。

GitFlowと比べてブランチ構成が単純で、develop・releaseのような中間ブランチを持ちません。ただし、featureブランチの生存期間そのものに明確な上限は定めていないため、レビュー待ちが長引くとブランチが数日〜数週間残ることもあります。

トランクベース開発：小さく頻繁に統合する戦略

トランクベース開発は、GitFlowやGitHub Flowと違い、ブランチの生存期間を数時間単位まで縮めることを前提にします。trunkbaseddevelopment.comの整理によれば、短命の機能ブランチ自体はコードレビューとCI（継続的インテグレーション）のチェック目的で使ってよいものの、そこから直接アーティファクトを作成・公開することは想定していません^*1。あくまでレビューのための一時的な分岐であり、最終的にはtrunkへ素早く統合する運用です。

トランクベース開発が継続的デリバリーと相性が良い理由

継続的デリバリー（CD）とは、コードの変更を本番環境へいつでもリリース可能な状態に保ち続ける開発手法です。トランクベース開発が継続的デリバリーの前提条件とされる理由は、マージの衝突リスクを最小化し、常にtrunkがデプロイ可能な状態を維持しやすくする点にあります。

マージ地獄を避ける仕組み

長命ブランチが複数存在すると、統合のタイミングでコンフリクト（競合）が積み重なり、解消作業に時間がかかる「マージ地獄」が発生しやすくなります。Martin Fowlerは、機能ブランチによる隔離が「早期の問題検出を妨げ、リファクタリングを阻害する」と指摘しています^*4。統合を先延ばしにするほど、差分が大きくなり衝突の解消コストが跳ね上がる関係にあるためです。

Fowlerは同時に、「1〜2日で機能を完成させるチームは、統合の遅延による問題を避けられるだけの頻度で統合できる」とも述べています^*4。統合間隔を短くすること自体が、マージ地獄を防ぐ直接的な対策になります。

Google Cloud DORAの調査が示す傾向

Google CloudのDORA（DevOps Research and Assessment）チームによる調査では、2016年・2017年のデータをもとに、ソフトウェアデリバリーと運用パフォーマンスが高いチームの特徴として次の条件が挙げられています^*5。

• リポジトリ内のアクティブなブランチ数が3本以下である
• ブランチを1日に1回以上trunkへマージしている
• コードフリーズ（一定期間の変更凍結）を実施していない
• リリース前の統合フェーズを別途設けていない

dora.devは、トランクベース開発を、ソフトウェアデリバリーと運用パフォーマンスの向上に寄与する実践（ケイパビリティ）の一つとして位置づけています^*5。ただしこれは、トランクベース開発そのものがデリバリー速度・安定性の全てを保証するという意味ではなく、あくまで高パフォーマンスチームに共通して見られる特徴という整理です。過度な承認プロセスを要するコードレビュー体制は、トランクベース開発の定着を妨げる要因としても指摘されています^*5。

また、dora.devの定義では、トランクベース開発は継続的インテグレーションの前提となる実践であり、継続的インテグレーションはトランクベース開発と、コミットごとに実行される高速な自動テストスイートの組み合わせとして説明されています^*5。ブランチ運用だけを変えても、テストが自動化されていなければ効果は限られます。

未完成機能を隠す2つの技法：フィーチャーフラグとブランチbyアブストラクション

ブランチを短命化すると、複数スプリントにわたる大きな機能はどうするのかという疑問が生じます。この課題に対応する技法が、フィーチャーフラグとブランチbyアブストラクションです。

フィーチャーフラグ（リリーストグル）

フィーチャーフラグとは、コードを変更せずにシステムの挙動を切り替えられる仕組みです^*6。未完成の機能をtrunkに統合しつつ、フラグをオフにすることで本番環境には表示させない、という使い方をします。Martin Fowlerは、3〜6ヶ月かかる機能を2週間ごとのリリースサイクルに乗せる場合の対応策として、この仕組みを挙げています^*6。

ただし、Fowler自身はフィーチャーフラグ（リリーストグル）を無条件に推奨しているわけではありません。優先順位としては、まず機能を小さな単位に分割して段階的にリリースする進め方を検討し、次にUIの入口部分だけを最後に差し替える「キーストーンインターフェース」の手法を試し、それでも隔離しきれない場合の最後の手段としてフィーチャーフラグを使うべきだとしています^*6。フラグの数が増えると条件分岐が複雑化し、削除し忘れた古いフラグがコードの可読性を下げる副作用があるため、導入後は棚卸しの運用も欠かせません。

ブランチbyアブストラクション

ブランチbyアブストラクションは、大規模な内部変更（例：ライブラリの置き換え、データストアの移行）をブランチで隔離せず、抽象化レイヤーを挟んで段階的に移行する手法です。Fowlerの記事では、十分にモジュール化されたシステムにおいて、ブランチによる隔離の必要性を減らす技法の一つとして紹介されています^*7。trunkbaseddevelopment.comも、長期間かかる変更を実現するための関連技法としてブランチbyアブストラクションとフィーチャーフラグの両方を挙げています^*1。

両者の使い分けは、変更の性質によって決まります。ユーザーに見える機能の段階的な公開にはフィーチャーフラグが向き、内部実装の置き換え（インターフェースは変えず実体だけ差し替える）にはブランチbyアブストラクションが向くという整理です。どちらも「trunkに統合しながら未完成部分を隠す」という共通の目的を持ちますが、隠す対象がユーザー向けの挙動か内部実装かで技法を選び分けます。

移行の4ステップと直面しやすい落とし穴

GitFlow等からトランクベース開発への移行は、ブランチ運用ルールを変更するだけでは完了しません。CI整備・レビュー体制・チームの合意形成を含む段階的な取り組みが必要です。

ステップ1：現状のブランチ運用を可視化する

まず、現在のアクティブブランチ数・平均生存期間・マージ頻度を把握します。DORAが指標として挙げるアクティブブランチ3本以下・1日1回以上のマージという基準^*5と比較することで、自チームがどの程度トランクベース開発から離れているかを客観的に把握できます。

ステップ2：レビューとCIパイプラインを整備する

ブランチの生存期間を縮めるには、レビューが滞留しない体制と、コミットごとに自動テストが走るCI環境が前提になります。レビュー待ちの時間が長い場合、レビュー担当者の割り当てルールやレビュー範囲の見直しが必要です。テストが自動化されていない場合は、ブランチ運用を変える前にテストの自動化に着手する必要があります。

ステップ3：featureブランチを短命化する

チーム全体でfeatureブランチの生存期間目標を設定し、大きすぎるタスクは小さな単位に分割します。分割しきれない機能には、フィーチャーフラグやブランチbyアブストラクションを適用し、未完成のままtrunkへ統合できる状態を作ります。

ステップ4：段階的にdevelop・releaseブランチを縮小する

GitFlowのdevelop・releaseブランチのような中間ブランチは、一度に廃止せず段階的に役割を縮小していく進め方が現実的です。並行運用の期間は終了条件（featureブランチの平均生存期間や本数の目標値）を先に決めておくと、移行が長期化して中途半端な状態が固定化することを避けられます。

移行で直面しやすい落とし穴

移行時に見落とされやすい点として、次の3つが挙げられます。

テスト未整備のままブランチ運用だけ変える失敗：CIによる自動テストが整っていない状態で統合頻度だけ上げると、trunkが壊れたまま気づかない期間が長くなるリスクがあります。dora.devの整理でも、トランクベース開発は高速な自動テストスイートとの組み合わせが前提とされています^*5。

フィーチャーフラグの棚卸し不足：フラグを増やす一方で削除の運用ルールを決めないと、コードベースに古い条件分岐が蓄積し、可読性と保守性が落ちていきます。

レビュー承認プロセスの負荷：dora.devは、複数人の承認を必要とする重いコードレビュー体制がトランクベース開発の定着を妨げる要因になると指摘しています^*5。承認者数やレビュー範囲を見直さずにブランチだけ短命化しようとすると、レビュー待ちの行列ができてしまいます。

外注の委託範囲と発注側が準備すべきこと

ブランチ戦略の移行は、Gitの操作知識だけでなく、CI/CD設計・テスト自動化・チームのレビュー文化までを横断する取り組みです。自社にDevOpsの専門知識を持つ人材が少ない場合、外部パートナーへの委託が現実的な選択肢になります。

外注で依頼しやすい3つの範囲

• プロセス設計：現状のブランチ運用の課題を診断し、featureブランチの短命化とフィーチャーフラグ導入の計画を策定する段階。既存のリリースサイクルやチーム体制を踏まえた移行ロードマップの作成を含みます。
• CI/CD整備：コミットごとに自動テストが走るパイプラインの構築、デプロイの自動化、フィーチャーフラグ管理の仕組みの導入。テスト自動化が未整備の場合はここから着手する必要があります。
• 伴走支援：移行期間中のレビュー体制の運用支援や、チームメンバーへの新しいワークフローの定着支援。移行直後は判断に迷う場面が増えるため、一定期間の伴走を依頼するケースがあります。

発注側が事前に準備すべきこと

外注を依頼する前に、次の情報を整理しておくと、委託先からの提案・見積もりの精度が上がります。

現在のブランチ運用の実態：使用しているブランチ戦略（GitFlow相当か、GitHub Flow相当か、独自ルールか）、アクティブブランチ数、リリース頻度の実績値です。

CI/CDの整備状況：テストの自動化率、CIパイプラインの有無、デプロイの自動化状況です。テストが自動化されていない領域を洗い出しておくと、移行計画の前提が明確になります。

チームの合意形成の状態：ブランチ戦略の移行はエンジニア全員の作業習慣に影響するため、経営層・開発リーダー・現場エンジニアの間で移行の目的と進め方について合意が取れているかを確認しておく必要があります。合意形成が不十分な状態で外注に着手すると、移行後の運用が現場に定着しない事態につながります。

移行後の運用を止めないためには、新しいブランチ運用ルールとCI/CD構成をドキュメント化してもらい、社内エンジニアが変更内容を再現・修正できる状態を残すことが重要です。委託範囲にドキュメント整備とナレッジ移転が含まれているかを、発注前に確認してください。

まとめ：ブランチ戦略移行の3つの判断軸

本稿では、GitFlow・GitHub Flow・トランクベース開発という3つのブランチ戦略の違いから、トランクベース開発が継続的デリバリーと相性が良い理由、フィーチャーフラグとブランチbyアブストラクションによる未完成機能の隠し方、移行の4ステップと外注の委託範囲までを整理しました。要点を3つに集約すると次のとおりです。

第一に、ブランチ戦略は優劣ではなく適用条件で選びます。バージョン管理された配布物にはGitFlow、頻繁なデプロイにはトランクベース開発が前提と噛み合います。第二に、移行はブランチ運用ルールの変更だけでは完了せず、CI整備・テスト自動化・レビュー体制の見直しが前提条件になります。第三に、外注はプロセス設計・CI/CD整備・伴走支援の範囲を発注側と事前に切り分け、移行後にドキュメントとナレッジが社内に残る形で依頼することが定着の鍵になります。

自社のリリース頻度とチーム体制を踏まえ、無理のない移行計画を立てることが、マージ地獄を避けながら継続的デリバリーへ近づく現実的な進め方です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：trunkbaseddevelopment.com「Trunk Based Development」（Paul Hammant他、随時更新）https://trunkbaseddevelopment.com/
2. *2　出典：Vincent Driessen「A successful Git branching model」（2010年1月、2020年3月に振り返り追記）https://nvie.com/posts/a-successful-git-branching-model/
3. *3　出典：GitHub「GitHub flow」（GitHub公式ドキュメント）https://docs.github.com/en/get-started/using-github/github-flow
4. *4　出典：Martin Fowler「FeatureBranch」https://martinfowler.com/bliki/FeatureBranch.html
5. *5　出典：Google Cloud DORA「Trunk-based development」（DORA 2016-2017年調査データに基づく分析）https://dora.dev/capabilities/trunk-based-development/
6. *6　出典：Martin Fowler「FeatureToggle」https://martinfowler.com/bliki/FeatureToggle.html
7. *7　出典：Martin Fowler「Patterns for Managing Source Code Branches」https://martinfowler.com/articles/branching-patterns.html

Tweet