外部チームと強く結合した開発でのブランチ戦略を考える

(gitの)ブランチ戦略の話から外部チームとの協業について考えるきっかけがあった。
以下の違和感など。

• featureブランチがなかなかマージされてない
• ある環境の都合でマージ順序が変わる
• develop/main以外に保守対象のブランチがある（保守具合は人によってまばら）

どこでブランチ運用が壊れ始めるか

ブランチはコード統合のための道具として単純に使いたい。が、実務では次の要求が入る。

• 未完成機能でも外部チームに先行利用してほしい
• 外部チームの検証タイミングに合わせて機能公開を調整したい
• 複数の開発を同時に見せたいが、本流にはまだ入れたくない

この時点で、ブランチは「統合管理」だけでなく「協業契約」まで背負い始めてる。

問題はブランチ戦略そのものではなく結合点にある

外部チームはコードではなく、最終的には API の振る舞いと結合している。
にもかかわらず、結合点が次のように運用されると複雑化しやすい。

• API 仕様や契約ではなく Git ブランチに依存する
• バージョンではなく特定環境の状態に依存する

この状態では、環境都合がブランチ運用を直接ゆがめる。

dev （でなくてもいいが何らかの）環境が「統合協業環境」となる

次の条件がそろうと、dev 環境は単なる開発者検証環境ではなくなる。

• 外部チームが日常的に利用する
• 複数の未リリース機能を同時に使う
• 一時的だが長期残存する機能がある

ここで起きるのは、開発者向け最適化と協業向け最適化の衝突。

Trunk-Based/CI/DXとの相性が良くない？

Trunk-Based と CI は、次の要素に最適化するイメージを持ってる。

• SSoT（mainブランチ）
• 早い統合
• 短命ブランチ
• 低い認知負荷

一方、外部協業では次を求められる。

• まだ統合したくない機能を先に使ってもらう
• 並行機能を合成した状態を維持する
• 速度より安定性を優先する

どちらが正しいかではなく、最適化対象が違うだけではある。

ブランチに背負わせすぎない

実務上は次の3つを分離して扱うと破綻しにくい。

1. 統合の世界（Git）
2. 協業の世界（環境）
3. 契約の世界（API / 振る舞い）

この3層をブランチ1本で表現しようとすると、運用は必ず重くなる。

現実的な結論

• ブランチは統合のために使う
• dev は合成環境であることを明示する
• 合成理由と期限を記録する
• 将来は API 契約やフラグに逃がせるものを逃がす

本来は「統合のためのブランチ運用」と「外部チームとの協業契約」は分離できるはずだ。が、 「理想に反している」ではなく、協業構造に合わせて最適化対象を切り替えていると考える方が現実的な場面もある。