「Git Flowはルールが多すぎて形骸化している」「GitHub Flowだと複数のリリースが並行した時に整理が難しい」……。

そんな悩みから辿り着いた、「リリース駆動型」のブランチ運用をご紹介します。

Git Flow の全体像

「リリース（版）」と「開発（進行）」を明確に分け、役割ごとにブランチを厳格に定義するスタイルです。

main (Production: 完成品のみ)
 ├ hotfix/x.x.x (本番の緊急修正) ──→ main & developへ
 └ develop (Next Release: 開発の主軸)
    ├ release/x.x (リリース準備・バグ修正) ──→ main & developへ
    └ feature/●● (個別の機能開発) ──→ developへ
  • 特徴: develop が常に存在し、すべての開発のベースとなる。
  • 弱点: 構造が複雑で、複数のリリースが並行すると develop がカオスになりやすい。

GitHub Flow の全体像

「常にデプロイ可能」であることを前提とした、極めてシンプルでスピード重視のスタイルです。

main (Production: 常にデプロイ可能)
 └ feature/●● (作業・修正・実験すべて) ──→ (プルリクエストを作成してレビュー)mainへ
  • 特徴: main から直接ブランチを切り、終わったらすぐ main に戻す。
  • 弱点: 本番反映のタイミングを遅らせたり、複数の機能を「一括で（でも一部は除いて）」リリースするような調整が難しい。

リリース駆動型（今回の運用）の全体像

基本思想は「リリースごとに独立した島を作る」ことです。

main (Production)
 ├ release/●● (リリースのハブ) ──→ mainへ
 │ ├ feature/●● (個別の作業) ──→ releaseへ
 │ └ feature/●● (リリースに対して複数人で作業する場合) ──→ releaseへ
 └ develop (実験場：フローからは独立)
  • 特徴: main と feature の間に、リリースごとの「防波堤（release/●● ）」を設けている。
  • 強み: リリース単位で「リリースするか・しないか」を独立して判断できる。

各ブランチの役割

  • main: 常に本番。リリース直前まで「完成品」以外は入れない。
  • release/●●: そのリリースの王様。全作業ブランチの合流地点。
  • feature/●●: 実際の作業用。
  • develop: 検証環境で「とりあえず動かしたい」時に使い、いつでも作成・破壊しても良い。マージのフローには一切含めません。何なら名前はdevelopである必要もありません。

なぜこの運用なのか？

このフローに辿り着いた背景には、起こりうるリスクが（実際に起きたことも）あります。

  • 「巻き込み事故」:
    develop ブランチがマージ経路のため、明日リリースの機能Aと、明後日リリースの機能Bが混ざることになります。しかし機能Aのリリースが延期され、「機能Bのコードが混ざっていて、機能Aだけを切り離せない」ということに陥る可能性があります。
  • 「検証環境がカオス」:
    一旦、動作確認をしたいコードが develop に溢れ、誰のコードのせいで環境が壊れているか不明になります。結果、「リリース前の大事なテストができない」という本末転倒な事態が起こりえます。
  • 「デプロイ凍結」:
    GitHub Flowのように main にマージした後に「やっぱりこの機能、次のキャンペーンまで出さないで」と指示が。main を戻す作業に追われ、その間他の緊急修正のリリースすらできなくなってしまう可能性があります。

これらを解決するため、「リリースの独立性を保ちつつ、遊び場（develop）を隔離する」今の形になりました。

ワークフロー

実際の開発フローをコマンドで追ってみましょう。

① スタート（mainからreleaseを作成）

git checkout main
git pull origin main
git switch -c release/●●
git push origin release/●●

② 作業開始（releaseからfeatureを作成）

git checkout release/●●
git switch -c feature/●●

③ 合流（featureからreleaseへマージ）

GitHubやBacklogなどのプルリクエスト（PR）経由で行います。
ここでチーム内レビューを行い、リリースとしての完成度を高めます。

④ 本番リリース（releaseからmainへマージ）

リリース直前、ついに main へ合流させます。
完了後、役目を終えた release/●● は削除します。

他の運用フローとの比較

項目 Git Flow GitHub Flow 今回の運用
思想 開発ラインを一本にまとめ、版を管理する 準備ができ次第、即座に本番へ届ける リリースごとに「島」を作り、干渉を遮断する
中心ブランチ develop main release/●●
リリースの単位 定期（一括） 随時（PRごと） リリースごと
事故のリスク 低いが複雑 混ざりやすい 極めて低い
developの扱い 必須（神聖） なし 任意（砂場）

運用前に知っておきたい「デメリットと注意点」

ここまでの内容で、とても優れた運用に見えますが、もちろん弱点もあります。
このフローを採用する際に覚悟しておくべきポイントを整理しました。

1. 「main からの同期」という宿命

複数のリリース対応が並行している場合、先に別のリリースが main にマージされると、自分の release ブランチは「古い状態」になります。

  • 注意点: 定期的に main を release に取り込まないと、最終的なマージ時に巨大なコンフリクト（衝突）が発生します。
  • 対策① こまめな同期: 「main に何かがマージされたら、全 release ブランチに main を pull する」という運用ルールを徹底しましょう。
  • 対策② ブランチを長生きさせない: そもそも「releaseブランチの寿命を短く保つ」という視点も不可欠です。ブランチの生存期間が延びるほど、他の変更と衝突するリスクは雪だるま式に膨れ上がります。1回のリリースに機能を詰め込みすぎず、開発の規模感とリリースサイクルの「ちょうどいい塩梅」を見極めて、なるべく短期間で main に合流させるスケジュール調整を心がけましょう。

2. 「合わせ技テスト」がしにくい

各 release ブランチが独立しているため、「リリースAとリリースBを混ぜた状態でテストしたい」という状況に弱いです。

  • 注意点: リリース同士が干渉しそうな場合、個別の release ブランチでのテストだけでは不十分なことがあります。
  • 対策: ここで develop ブランチの出番です。一時的に develop に両方の release をマージして動作確認を行うか、確認用の「統合ブランチ」を別途作って検証しましょう。

3. ホットフィックス（緊急修正）の対応

本番環境（main）でバグが見つかり、緊急修正を行った場合の対応が少し面倒です。

  • 注意点: main で直した内容は、現在動いているすべての release ブランチにも手動で反映させる必要があります。これを忘れると、次のリリース時に「直したはずのバグが先祖返りして復活する」という悲劇が起きます。
  • 対策: 1の時と同じく「ホットフィックス（緊急修正）対応後も、全 release ブランチに main を pull する」というルールを徹底しましょう。

4. 放置された「ブランチの森」

リリースごとにブランチを作るため、意識しないと Git のブランチ一覧がカオスになります。

  • 注意点: リリースが終わった release/●● や feature/●● が残り続けると、どれが最新か分からなくなります。
  • 対策: 「マージしたら即削除」を徹底し、定期的に大掃除する運用が必要です。

まとめ：この運用のメリット

  • 精神的安全性: main を汚さず、release も他リリースの影響を受けない。
  • 柔軟性: 「やっぱりこのリリース中止で！」がPRを閉じるだけで完結する。
  • スピード: develop で壊れることを恐れず試行錯誤できる。

「複数のリリース対応が並行し、リリース判定が慎重な現場」には、この「隔離型」の運用が非常にマッチします。
「今のGit運用、ちょっと窮屈だな」と感じている方の参考になれば幸いです。