安定性は開発ブランチではなく品質管理で守り、トランクに小さく積んで依存の版を1つに保つ。書籍はこのトランクベース開発を最もスケールする方針とする。
目次
ブランチが増えるほど変更は重くなる
分岐の数だけ、1つの変更が届くべき範囲が広がる
- 型名の改名も、全ブランチと手元の変更まで追うと手間が跳ね上がる
- マージは小さいほど楽。長命ブランチが複数あると協調コストが急増
- ブランチからブランチを切り始めたら危険信号。正本は1つにする
安定性はブランチでなく品質管理で守る
隔離よりテスト・CI・コードレビューを徹底する方がうまく解ける
- トランクへ小さく頻繁にコミットし、未完成の機能は実行時に無効化
- 約1,000チーム中、dev ブランチを持つのは2〜3チームだけ（§16.3.4）
- リリースブランチは間隔が長いなら妥当。日に何度も出せるなら不要に
依存の版は1つだけにする
どの依存も、選べる版が1つしかない状態（One Version）に保つ
- 版を選べると、マージ戦略の議論やダイヤモンド依存が生まれる
- 古い版との互換性の約束は高くつくので最小限にする
モノリポは手段であって目的ではない
大事なのはモノリポかどうかではなく、単一バージョンを守ること
- モノリポなら単一バージョンをほぼ自明に守れる
- 巨大リポジトリには性能の制約や、機密・法務の要件の違いがある
- 連合型（バーチャルモノリポ）が事実上の標準になると書籍は見る
関連
- ソフトウェアエンジニアリングとは何か — 開発ブランチはスケールしないポリシーの一例
- テスト — ブランチの代わりに安定性を担うもの
- コードレビュー — 小さな変更