【Git】ブランチ戦略を比較してみた

はじめに

チーム開発をしていると、どのようなブランチ戦略を採用するか悩むことがあります。

本記事では、代表的なブランチ戦略である Git Flow、GitHub Flow、GitLab Flow、Trunk-Based Development について、それぞれの特徴やメリット・デメリットを比較していきます。

ブランチ戦略とは

ブランチ戦略とは、チームでGitを使って開発する際のブランチの命名規則や運用ルールを定めたものです。

適切なブランチ戦略を採用することで、以下のメリットが得られます。

• コードの品質管理がしやすくなる
• 複数人での並行開発がしやすくなる
• リリース管理が整理される
• CI/CDパイプラインとの統合がスムーズになる

Git Flow

Git Flowは2010年にVincent Driessenが提唱したブランチモデルです。

A successful Git branching model

In this post I present a Git branching strategy for developing and releasing version-based software.

原著のページ冒頭には2020年3月付けで次のような注釈が掲載されています（以下、意訳）。

Gitフローは2010年の公開以来広く普及したが、継続的デリバリーを行うWebアプリケーションのチームには、GitHub Flowのようなシンプルなワークフローを推奨する。Git Flowは複数バージョンをサポートする必要があるバージョン管理されたソフトウェアには依然として適している。

ブランチ構成

メインブランチ

• master（現代のプロジェクトでは main を使うことも多い）：
  • 本番環境で即座にデプロイできる状態を常に保つブランチ
  • 各コミットが新しいプロダクションリリースを表し、バージョン番号でタグ付けされる
• develop：
  • 次のリリースに向けた最新の開発変更を統合するブランチ
  • ナイトリービルドの起点となる

補助ブランチ

• feature/*：
  • 新機能の開発用
  • develop から分岐し、develop に戻す
  • 命名は master、develop、release-*、hotfix-* 以外であれば任意
  • 基本的に開発者のローカルリポジトリにのみ存在する
• release/*：
  • 本番リリースの準備用
  • develop から分岐し、完了後は master と develop の両方にマージする
  • バージョン番号の更新や軽微なバグ修正もここで行う
• hotfix/*：
  • 本番環境の緊急バグ修正用
  • master から分岐し、完了後は master と develop の両方にマージする
  • release ブランチが存在する場合は develop の代わりに release ブランチにマージする（release ブランチ完了時に develop へも自動的に取り込まれる）

フロー

1. develop から feature ブランチを切る
2. 機能開発後、develop に --no-ff オプションを付けてマージする（ブランチの存在を履歴に残し、後からの追跡や差し戻しを容易にするため）
3. リリース準備ができたら develop から release ブランチを切る
4. release ブランチでバージョン番号更新・最終調整後、master と develop の両方にマージしてタグを打つ
5. 本番環境でバグが発生したら master から hotfix ブランチを切り、修正後に master と develop にマージ

メリット・デメリット

メリット

• master と develop を分離することで開発中のコードと本番コードを明確に分けられる
• リリースブランチで本番リリース前の最終調整ができる
• 定期リリースや正式なQAプロセスがあるプロジェクトに向いている
• 複数バージョンの並行サポートができる

デメリット

• 管理するブランチ数が多く複雑になる
• 小規模プロジェクトや継続的デプロイには過剰なオーバーヘッドになる
• 長期ブランチが多くなり、マージコンフリクトが発生しやすい

GitHub Flow

GitHub Flowは、GitHubが提唱する軽量でブランチベースのワークフローです。（ブランチ戦略としてよく取り上げられますが、下記の公式ドキュメントを読む限り、ブランチ戦略というよりはGitHub上での開発フローのガイドラインのようなものに近い印象です）

GitHub フロー - GitHubドキュメント

GitHub フローに従って、プロジェクトで共同作業を行います。

ブランチ構成

• main（デフォルトブランチ）：
  • 常にデプロイ可能な状態を維持する
• 作業ブランチ：
  • increase-test-timeout や add-code-of-conduct のような短くて説明的な名前を付ける

フロー

1. ブランチ作成：main から作業ブランチを切る
2. 変更の実施：ブランチ上でファイルを作成・編集・削除する。各コミットは孤立した完全な変更を含むべき（例：変数のリネームとテスト追加は別々のコミットにする）
3. Pull Request作成：変更内容と解決する問題を要約したPull Requestを作成する
4. レビューコメント対応：レビュアーからの質問や提案に対し、ブランチ上で追加コミットして対応する
5. Pull Requestのマージ：承認後、デフォルトブランチにマージする
6. ブランチ削除：マージ後にブランチを削除して作業完了を示す

メリット・デメリット

メリット

• シンプルで理解しやすく、導入コストが低い
• ブランチ管理が最小限で済む
• main を常にデプロイ可能な状態に保つ設計のため、継続的デリバリーとの相性が良い

デメリット

• ステージング環境の管理はワークフロー自体に定義されていないため、別途CI/CDで対応する必要がある
• 単一の main ブランチのみを前提とする設計のため、複数バージョンの並行サポートには対応できない
• main にマージする前のレビューとテストの質がそのまま本番品質に直結するため、テスト体制が整っていないと品質リスクが高まる

GitLab Flow

GitLab Flowは、GitLabが提唱するブランチ戦略です。Git Flowの複雑さを排しながら、GitHub Flowにはない複数環境へのデプロイ管理を取り込んでいます。コミットは常に下流に向かって流れるというシンプルな原則のもと、main ブランチを起点として環境ブランチへ段階的に展開することで、本番リリースまでの変更の流れを一方向に保ちます。

GitLab Flowとは

コードレビューを行うとバグを特定するための体系的な評価が得られ、デベロッパーは最高品質のコードを作成できるようになります。

Git Flowとの大きな違いは、デフォルトブランチが develop ではなく main であることです。これにより、リリース・タグ付け・マージのオーバーヘッドを削減できます。

ブランチ構成

• main：
  • すべての機能と修正が集約される主要ブランチ
• 環境ブランチ（test、acceptance、production など）：
  • デプロイ先の環境に対応するブランチ。必要な数だけ柔軟に追加できる（例：main → test → acceptance → production）
• feature/*：
  • 個別の機能開発用ブランチ
• バージョンブランチ（v1、v2 など）：
  • 複数のAPIバージョンや長期サポートが必要な場合に使用

フロー

1. main から feature ブランチを切る
2. 機能開発後、main にマージ
3. main から環境ブランチへ下流に向かって段階的にマージしてデプロイ（例：main → test → acceptance → production）
4. すべての環境でテストが完了したら production ブランチにマージして本番リリース

メリット・デメリット

メリット

• リリース・タグ付け・マージのオーバーヘッドをGit Flowより削減できる
• すべての変更が本番到達前にすべての環境でテストされるためコード品質が向上する
• チームサイズを問わず柔軟に対応できる

デメリット

• 環境ブランチが増えるほど管理するブランチ数が増え、管理コストが上がる
• 各環境間でコードの差異（ドリフト）が生まれるリスクがある
• 複数バージョンのサポートにはバージョンブランチの管理が別途必要になる

Trunk-Based Development

Trunk-Based Developmentは、全開発者が trunk（または main）と呼ばれる単一ブランチに対して協力して開発するブランチモデルです。長期的な開発ブランチを作らないことが原則です。

Trunk Based Development

A portal on this practice

チーム規模による2つのパターン

スモールチーム

• trunk に直接コミット・プッシュする
• プロセスのオーバーヘッドが最小限
• ペアプログラミングやモブプログラミングとの相性が良い

スケールチーム

• 短期的なフィーチャーブランチを作成する（単独または2人で担当）
• ブランチはコードレビューとCIによるビルド検証を目的とするもので、アーティファクトの作成はtrunkへの統合後に行う
• Pull Requestワークフローを用いてtrunkにマージする

フロー

1. trunk から短期間のフィーチャーブランチを切る（またはスモールチームでは直接コミット）
2. コミット前に開発者のワークステーション上でビルド・ユニットテスト・統合テストを実施する
3. 小さな変更を1日に複数回 trunk にコミット・マージする（CIの要件として24時間以内の統合を満たすため）
4. 未完成の機能はフィーチャーフラグで隠す。長期にわたる変更には branch-by-abstraction を用いる
5. 常に trunk がデプロイ可能な状態を維持する

フィーチャーフラグとは、条件分岐によって機能のオン/オフを実行時に切り替える手法です。開発中の機能をそのまま trunk にマージしつつ、フラグが有効なときだけ動作するようにすることで、長期ブランチを作らずに未完成の機能を統合し続けられます。機能がリリース済みになったらフラグは削除します。

branch-by-abstractionとは、大規模なリファクタリングや既存実装の置き換えを、ブランチを作らずに trunk 上で進めるための手法です。置き換え対象のコードに抽象化レイヤーを設け、旧実装と新実装を切り替えられる状態にしながら段階的に移行します。完了後は抽象化レイヤー自体も削除します。

リリース戦略

Trunk-Based Developmentでは2つのリリース方法があります。

• just-in-time リリースブランチ：リリース直前に trunk からリリースブランチを切り、そのブランチ上で別途強化・安定化作業を行い、リリース後は削除する
• trunk からの直接リリース："fix forward" 戦略を用いてtrunkから直接リリースする

メリット・デメリット

メリット

• 継続的インテグレーションが自然に強制される
• 長期ブランチがないためマージコンフリクトを最小化できる
• 継続的デリバリー・継続的デプロイとの相性が最も高い
• チームのスループットや品質を落とさずスケールできる

デメリット

• 高度なテスト体制とCIパイプラインの整備が前提となる
• フィーチャーフラグやbranch-by-abstractionの実装・管理が必要になる
• trunk に不具合が混入するリスクが常に存在する

CI/CD との相性

各ブランチ戦略の特徴から CI（継続的インテグレーション）・CD（継続的デリバリー）との相性を整理してみます。

どのブランチ戦略がCI/CDと合うかは、チームの実情によって変わります。CI/CDの成熟度やリリース頻度、チームの規模などを考慮して、適切な戦略を選択することが重要です。ブランチ戦略を先に選んでCI/CDを設計する場合もあれば、目指すCI/CDのあり方からブランチ戦略を選ぶ場合もあります。

どれを選べばいいか

各戦略の選び方の目安を以下に示します。

Git Flow

• 定期的なリリースサイクルがあるプロジェクトに向いている
• 複数バージョンを並行サポートする必要がある場合に検討しやすい（モバイルアプリ・ライブラリ等）
• 本番へのリードタイムが長くなることを許容できる環境であれば選択肢になりうる

GitHub Flow

• シンプルさを重視する個人開発や小規模チームに向いている
• 継続的デリバリーを行うWebアプリケーションとの相性が良い
• CI設定をシンプルに保ちながら、変更を頻繁に届けたいチームにも向いている

GitLab Flow

• ステージング・本番など複数の環境が必要なチームに向いている
• GitHub Flowよりも少し構造が欲しい場合に検討しやすい
• 環境ごとにデプロイパイプラインを段階的に管理したい場合に向いている

Trunk-Based Development

• 高速な開発サイクルを必要とするチームに向いている
• 高速なCIパイプラインやテスト体制が十分に整っていることが前提になる
• 継続的デリバリーを重視するなら最も相性の良い選択肢になりうる

まとめ

本記事では4つのブランチ戦略について比較しました。

それぞれの戦略にトレードオフがあり、「これが最善」というものはありません。チームの規模、リリース頻度、プロジェクトの性質、CI/CDの整備状況に合わせて適切な戦略を選択することが重要です。

また、一度戦略を採用しても、プロジェクトの成長に合わせて見直すことも大切です。例えば、最初はGitHub Flowでシンプルに始め、プロジェクトが大きくなってきたらGitLab FlowやTrunk-Based Developmentに移行するといったアプローチも有効だと思います。

各戦略のイメージ図

最後に各ブランチ戦略のイメージ図をClaude Designで作成してみました。イメージを掴むのに役立てば幸いです。

参考

• A successful Git branching model（Git Flow 原著）
• GitHub flow（GitHub公式ドキュメント）
• GitLab Flowとは
• Trunk Based Development（公式サイト）