ブランチを切ってからマージされるまでの時間はどのくらいであるべきかを考えてみる。

コードベース

まず、コードベースは１つであるべき。Git で言えばリモートリポジトリは１つにするということ。

もし複数のコードベースがある場合、それはアプリケーションではない – それは分散システムである。

The Twelve-Factor App （日本語訳） (12factor.net)

よくある（よくない）パターンとしては、開発チーム用と顧客用リポジトリを分ける、開発環境・テスト環境・本番環境でリポジトリを分けるなど。

直近だとこういう事例がある。

AWSは現在GitHubで公開されているAWSドキュメントの廃止を行う。プロジェクトの結果を検討し、内部ドキュメントを手作業で同期するオーバーヘッドを考慮した結果、公開リポジトリのほとんどを廃止を決定した。

AWSがGitHubで公開している公式ドキュメントを廃止 (infoq.com)

ブランチを分ける

コードベースは1つであるべきだが、コードベース内でブランチを分けることはいくつかの正当な理由がある。未テストの動かないコードや未レビューの怪しいコードが混ざり込まないようにするためなど。

分け方は下記が参考になる。

ソースコードブランチ管理のパターン – Martin Fowler’s Bliki (ja) (bliki-ja.github.io)

ブランチの生存時間

ブランチの生存時間は短くあるべきだ。期間が長くなるほど差分が肥大化し、マージが困難になる。

コードの流れはひとつだけである。一時的なブランチで開発することもできるが、数時間以上も維持してはいけない。

『エクストリームプログラミング』ＫｅｎｔＢｅｃｋ, ＣｙｎｔｈｉａＡｎｄｒｅｓ著

経験則としては、「誰もが毎日メインラインにコミットする」、正確には「1 日以上の作業がインテグレーションされていない状態でローカルリポジトリにあってはいけない」ということ

ソースコードブランチ管理のパターン – Martin Fowler’s Bliki (ja) (bliki-ja.github.io)

1日以上の作業になるとそこそこの巨編になる。レビューもつらいし何が目的の修正かも見えづらくなる。

統合はいいがリリースしたくない

メインにマージすると本番環境に公開されるからブランチを分けておきたくなる衝動と戦う必要がある。

対策としては設定（フィーチャートグル、FeatureToggle）によって機能を無効化しておくか、内部機能はデプロイするがユーザーインターフェースの公開を後に回して結果的に機能を使えない状態にする（KeystoneInterface）方法がある。