どうも、拓田です。
「ブランチ戦略」って言葉、なんとなく聞いたことあるけど「Git Flow？GitHub Flow？何が違うの？」ってなりませんか？
さらに「コンフリクトを防ぐ」という話になると、バックマージ・cherry-pick・upstream firstといった言葉が出てきて余計ごちゃごちゃする。
今回はブランチ戦略の種類とコンフリクト管理の手段を、整理しました。
1. ブランチ戦略の種類
Git Flow
複数のブランチを使って開発・リリースを厳密に管理する戦略です。
main ← 本番環境。常にリリース可能な状態
develop ← 開発の主軸。featureブランチの統合先
feature ← 個々の機能開発。developから分岐
release ← リリース前の最終調整。developから分岐
hotfix ← 本番のバグ緊急修正。mainから分岐
流れはこんな感じ：
feature → develop → release → main
↑
hotfix（緊急時）
✅ 管理上の課題と対策
| 課題 | 管理方法 |
|---|---|
| マージコンフリクトの多発 | featureブランチを小さく・短命に保つ。定期的にdevelopの最新をfeatureに取り込む |
| マージミス・事故 | mainとdevelopへの直接pushを禁止。プルリクエストのレビュー承認を必須にする |
| 長期ブランチによるマージ地獄 | フィーチャーフラグを使い、ブランチを長生きさせない |
向いている用途： バージョン管理が必要なアプリ・リリースサイクルが決まっているプロジェクト（例：モバイルアプリ）
GitHub Flow
シンプルに main と feature ブランチだけで管理する戦略です。
main ← 常にデプロイ可能な状態
feature ← 作業ブランチ。mainから分岐してmainに戻す
流れはシンプル：
main → feature（作業）→ プルリクエスト → レビュー → main
向いている用途： 継続的デプロイ・Webサービス・小〜中規模チーム
GitLab Flow
GitHub Flow にリリースブランチの概念を追加した戦略。開発の主軸は main ブランチです。
main（開発の主軸）
└── feature（作業）→ mainにマージ
↓
release/v1.0 ← リリースタイミングでmainから切り出す
release/v2.0 ← 次のバージョン
重要な理解：featureブランチではなくmainが軸
mainで開発を継続しながら、リリースタイミングで release/v1.0 を切り出す構造です。
・mainで開発を継続しながら
・release/v1.0はv1.0のバグ修正だけに集中できる
・release/v2.0は並行して次バージョンの準備ができる
→「開発の継続」と「リリースの安定」を分離できるのが強みです。
向いている用途： 中〜大規模・バージョン管理あり
Trunk Based Development
全員が短命な feature ブランチを使い、毎日 main にマージする戦略。Google などの大規模開発で採用されています。
・featureブランチの寿命は最大1〜2日
・フィーチャーフラグで未完成機能をOFFにしたままmainにマージ
・CIで自動テストを徹底してmainの品質を担保
向いている用途： 大規模・継続的デプロイ・CI/CD徹底
規模別の使い分けまとめ
| 規模 | 向いている戦略 |
|---|---|
| 小〜中規模・高頻度デプロイ | GitHub Flow |
| 中〜大規模・バージョン管理あり | GitLab Flow |
| 大規模・継続的デプロイ・CI/CD徹底 | Trunk Based Development |
| バージョン管理が厳密に必要 | Git Flow |
2. コンフリクトを防ぐ3つの手段
まず「上位・下位ブランチ」を理解する
上位 → main （開発の主軸・最新・起点）
下位 → release/v1.0 （mainから切り出したもの）
「上位・下位」の基準は開発の流れの起点がどこか。release/v1.0 は main から切り出して作ったため、main が上位になります。
バックマージ
下位ブランチの変更を上位ブランチに反映させてズレをなくす操作です。
【状況】
release/v1.0でバグ修正した
↓
mainにも同じ修正を反映させないと
v2.0に同じバグが残ってしまう
↓
release/v1.0 → mainにバックマージして
両者のズレをなくす
⚠️ 注意： バックマージはコンフリクトをなくすための操作ではなく、内容のズレをなくすための操作。むしろバックマージ自体がコンフリクトを引き起こすリスクがあります。
バグ修正はこんな流れが安全です：
release/v1.0
↓ ブランチを切る
hotfix/issue-123（バグ修正作業）
↓ プルリクエスト
release/v1.0にマージ
↓
mainにもバックマージ
release/v1.0に直接コミットせず hotfix ブランチを切る理由は、レビューを挟めることと修正失敗時のリスクを局所化できることです。
cherry-pick
特定のコミットだけを別のブランチに持っていく操作です。ブランチ全体をマージするのではなく、欲しいコミットだけを抜き出します。
【状況】
main：
コミットA（v2.0の新機能）
コミットB（v2.0の新機能）
コミットC（バグ修正） ← これだけrelease/v1.0に持っていきたい
コミットD（v2.0の新機能）
【cherry-pick】
git cherry-pick コミットC
release/v1.0：
コミットC（バグ修正）だけが適用される
バックマージとの違い：
バックマージ → ブランチ全体をマージするためv2.0の変更と衝突しやすい
cherry-pick → 必要なコミットだけ持っていくためコンフリクトリスクが最小限
upstream first（上流優先）
上位ブランチ（main）で先に修正してから下位ブランチに持っていく運用方針です。
【upstream firstの流れ】
mainでバグ修正
↓ cherry-pickで
release/v1.0にも適用
バックマージとの比較：
| 運用 | 流れ | リスク |
|---|---|---|
| バックマージ | release/v1.0で修正 → mainに戻す | バックマージ忘れのリスクあり |
| upstream first | mainで修正 → release/v1.0にcherry-pick | mainが常に最新を保てる |
✅ よくある誤解：
upstream firstを徹底していても「v2.0の開発が進むこと」は普通に起きます。upstream firstが防ぐのは「バックマージ忘れ」であって、開発の進行を止めるものではありません。
3つの手段の整理
| 手段 | 種類 | 目的 |
|---|---|---|
| バックマージ | 操作 | 下位ブランチの変更を上位ブランチに反映してズレをなくす |
| cherry-pick | 操作 | 特定コミットだけを別ブランチに持っていきコンフリクトリスクを下げる |
| upstream first | 運用方針 | 上位ブランチで先に修正してズレ自体を発生させない |
重要： cherry-pick だけが「操作」であり、バックマージと upstream first は「運用の方針」。cherry-pick はどちらの文脈でも使える道具です。
まとめ
- 🌱 ブランチ戦略は規模・リリース頻度・チーム体制によって使い分ける
- 🔀 Git Flowはブランチが多く複雑だが、バージョン管理が厳密に必要な場合に有効
- ⚡ GitHub Flowはシンプルで高頻度デプロイに向いているが、大規模では限界がある
- 🏢 GitLab Flowはmainを軸にリリースブランチでバージョン管理する中〜大規模向け
- 🚀 Trunk Based Developmentは短命ブランチとCI/CDを徹底した大規模向け
- 🔧 バックマージ・cherry-pick・upstream firstはズレやコンフリクトを管理するための手段であり、それぞれ「操作」と「運用方針」の違いがある
ブランチ戦略は「これが正解」というものではなく、チームの規模や開発スタイルに合わせて選ぶものです。まずは GitHub Flow から始めて、必要に応じて複雑な戦略に移行するのが現実的だと思います。