はじめに

master と feature だけで回すブランチ運用は、シンプルで分かりやすい反面、
規模や変更の幅が少しずつ広がると「限界」が見え始めます。
本記事では、よくある落とし穴と、今は大丈夫に見えてしまう理由、
そしてどのタイミングで次の一手を考えるべきかを整理します。

複数修正の一括リリースとブランチ戦略の関係

ブランチ構成
- master：本番相当の安定ブランチ
- feature/○○：機能開発用ブランチ（タスク単位で作成）
運用フロー
1. 古い master から feature/○○ を作成
2. 対象の feature ブランチを QA 環境にデプロイしてテスト
3. QA 完了後、feature → master にマージ

develop や staging ブランチはなく、
master ＋ feature だけのシンプル構成になっている。

この構成はシンプルな反面、通常は次の問題を抱えやすい。

QA 環境が「検証中の feature ブランチ専用」となり、
- 毎回切り替え作業が必要
- 「今 QA に入っているのはどの機能か」が分かりづらい
複数の修正を「1回のリリースにまとめたい」時に、
- まとめ先となる release ブランチがない
- 「リリース対象だけを束ねる」作業がやりづらい
古い master から切った feature ブランチが長生きすると、
- master との乖離が大きくなる
- マージ時にコンフリクト多発
- QA した状態と、実際に master にマージされた状態がずれやすい

本来であれば、規模が大きくなるほど破綻しやすい構成です。

この運用でも目立ったトラブルが起きにくい背景として、

変更の影響範囲が局所的になっている

という状況が挙げられます。

機能や領域ごとに構造が分かれている場合、
- 1つの feature ブランチが触る範囲は限定されやすい
- 他領域の変更と衝突しにくい
結果として、
- master の更新頻度がそこそこ高くても
- 実際にコンフリクトするファイルが限られる
  → 「古い master から切った feature でも、マージ時のダメージがまだ小さい」

そのため、
「QA 環境を feature ごとに張り替える」運用でも、
いまのところ現実的なコストに収まっている。

とはいえ、影響範囲が局所化しているだけで「たまたま耐えられている」側面もある。

特にドメイン駆動設計のように複数の領域をまたいで触る開発が増えると、
一気に壊れやすくなる可能性がある。
逆に言えば、いまの運用が何とか回っているのは、
ある意味で冗長かつトランザクションスクリプト的な分割に助けられている面もある。

このフェーズに入ったタイミングで、

といった一段だけ重いブランチ戦略に切り替える必要が出てきます。

master ＋ feature だけの構成はシンプルだが、
- QA 環境の切り替え負荷
- feature の長期化による乖離とコンフリクト
- 複数修正を1回のリリースで束ねづらい
  といった弱点を抱えやすい。
それでも今は問題が顕在化していないのは、
- 変更範囲と QA の対象が局所的に閉じている
  から。
ただし、横断的な変更が増えると限界が見える。

そのタイミングで、

といった最小限のブランチ追加を検討すると、現場の説得材料にしやすい。