\ この記事が役に立ったと思ったら、サポートお願いします！ /
チーム開発をしていると、どのようなブランチ戦略を採用するか悩むことがあります。
本記事では、代表的なブランチ戦略である Git Flow、GitHub Flow、GitLab Flow、Trunk-Based Development について、それぞれの特徴やメリット・デメリットを比較していきます。
ブランチ戦略とは、チームでGitを使って開発する際のブランチの命名規則や運用ルールを定めたものです。
適切なブランチ戦略を採用することで、以下のメリットが得られます。
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 へも自動的に取り込まれる）develop から feature ブランチを切るdevelop に --no-ff オプションを付けてマージする（ブランチの存在を履歴に残し、後からの追跡や差し戻しを容易にするため）develop から release ブランチを切るrelease ブランチでバージョン番号更新・最終調整後、master と develop の両方にマージしてタグを打つmaster から hotfix ブランチを切り、修正後に master と develop にマージメリット
master と develop を分離することで開発中のコードと本番コードを明確に分けられるデメリット
GitHub Flowは、GitHubが提唱する軽量でブランチベースのワークフローです。（ブランチ戦略としてよく取り上げられますが、下記の公式ドキュメントを読む限り、ブランチ戦略というよりはGitHub上での開発フローのガイドラインのようなものに近い印象です）
GitHub フロー - GitHubドキュメント
GitHubフローに従ってプロジェクトで共同作業を行います。
main（デフォルトブランチ）：
increase-test-timeout や add-code-of-conduct のような短くて説明的な名前を付けるmain から作業ブランチを切るメリット
main を常にデプロイ可能な状態に保つ設計のため、継続的デリバリーとの相性が良いデメリット
main ブランチのみを前提とする設計のため、複数バージョンの並行サポートには対応できないmain にマージする前のレビューとテストの質がそのまま本番品質に直結するため、テスト体制が整っていないと品質リスクが高まる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 など）：
main から feature ブランチを切るmain にマージmain から環境ブランチへ下流に向かって段階的にマージしてデプロイ（例：main → test → acceptance → production）production ブランチにマージして本番リリースメリット
デメリット
Trunk-Based Developmentは、全開発者が trunk（または main）と呼ばれる単一ブランチに対して協力して開発するブランチモデルです。長期的な開発ブランチを作らないことが原則です。
Trunk Based Development
A portal on this practice
スモールチーム
trunk に直接コミット・プッシュするスケールチーム
trunk から短期間のフィーチャーブランチを切る（またはスモールチームでは直接コミット）trunk にコミット・マージする（CIの要件として24時間以内の統合を満たすため）trunk がデプロイ可能な状態を維持するフィーチャーフラグとは、条件分岐によって機能のオン/オフを実行時に切り替える手法です。開発中の機能をそのまま trunk にマージしつつ、フラグが有効なときだけ動作するようにすることで、長期ブランチを作らずに未完成の機能を統合し続けられます。機能がリリース済みになったらフラグは削除します。
branch-by-abstractionとは、大規模なリファクタリングや既存実装の置き換えを、ブランチを作らずに trunk 上で進めるための手法です。置き換え対象のコードに抽象化レイヤーを設け、旧実装と新実装を切り替えられる状態にしながら段階的に移行します。完了後は抽象化レイヤー自体も削除します。
Trunk-Based Developmentでは2つのリリース方法があります。
trunk からリリースブランチを切り、そのブランチ上で別途強化・安定化作業を行い、リリース後は削除するメリット
デメリット
trunk に不具合が混入するリスクが常に存在する各ブランチ戦略の特徴から CI（継続的インテグレーション）・CD（継続的デリバリー）との相性を整理してみます。
| 戦略 | CI | CD（継続的デリバリー） |
|---|---|---|
| Git Flow | 並行ブランチが多くCI設定が複雑になりやすい | develop→release→masterという長いフローが必要なため本番へのリードタイムが長くなりやすく、相性は低い |
| GitHub Flow | mainへのPRとマージのみ対応すればよくシンプル | mainが常にデプロイ可能な設計のため、マージ後すぐにデリバリーできる |
| GitLab Flow | feature→mainのCIはシンプルだが、環境ブランチごとのデプロイパイプラインも別途必要 | 環境ブランチへの段階的マージがCDパイプラインと対応しやすく、相性が良い |
| Trunk-Based Development | 頻繁なtrunkへの統合のため、高速・高信頼なCIパイプラインが必須 | trunkが常にデプロイ可能であることが前提のため、4戦略の中で最も相性が高い |
どのブランチ戦略がCI/CDと合うかは、チームの実情によって変わります。CI/CDの成熟度やリリース頻度、チームの規模などを考慮して、適切な戦略を選択することが重要です。ブランチ戦略を先に選んでCI/CDを設計する場合もあれば、目指すCI/CDのあり方からブランチ戦略を選ぶ場合もあります。
各戦略の選び方の目安を以下に示します。
Git Flow
GitHub Flow
GitLab Flow
Trunk-Based Development
本記事では4つのブランチ戦略について比較しました。
それぞれの戦略にトレードオフがあり、「これが最善」というものはありません。チームの規模、リリース頻度、プロジェクトの性質、CI/CDの整備状況に合わせて適切な戦略を選択することが重要です。
また、一度戦略を採用しても、プロジェクトの成長に合わせて見直すことも大切です。例えば、最初はGitHub Flowでシンプルに始め、プロジェクトが大きくなってきたらGitLab FlowやTrunk-Based Developmentに移行するといったアプローチも有効だと思います。
最後に各ブランチ戦略のイメージ図をClaude Designで作成してみました。イメージを掴むのに役立てば幸いです。
