動機
某社とか某社とか、頭悪いことしてるなーと感じたので少なくともマトモと言えそうなレベルのワークフローを考えてみた。もっとも、某社とか某社とかのそれはどう転んでもマトモではないのだけれど。
そもそも分割する理由
- 単一のリポジトリで大規模開発するとpushの頻度が上昇してそれらの変更を取り込んでいる間に別のpushが入り...と際限がなくなってpushできなくなってしまう。その対策としてツリーを分割して一度に衝突する頻度を減らす。
- 共通部分とそうではない部分を分けて共通部分を一箇所にまとめる。
2は別の話題なので後で考えることにして、今は1を考える。
問題点
サブリポジトリをそれぞれメンテナンスしなければならなくなる。また全体をブランチする場合にはHgではマルチヘッドになってくれるもののサブリポジトリもブランチする必要があり、また後でそれぞれマージしなければならず、面倒かつ間違いが入り込む余地ができてしまう。
解決法
サブリポジトリの代わりにモジュールごとにブランチを切る。そして各ブランチで修正する範囲を開発規約で決めておく。これらのブランチは普通の使い方のブランチの子ブランチとする。
これでpushの衝突はリポジトリの分割と同様に減るし、開発規約で修整範囲を限定しているのでモジュールを跨ぐ修正が必要かつそれがコンフリクトするレアケースを除いて1マージで衝突することもない...つまり概ね自動でマージできる。
全体のブランチの下にモジュールのブランチを切るという要領で、GitであればbranchName/moduleNameのように命名しておく。Hgはブランチ名にかなり制限があるのでちょっと考えなければならないが、あるいはモジュールをブックマーク2にしてもいいかも知れない。
2(共通部分をまとめる)について
Gitではサブツリーマージで一つに纏められるが、いつかは分けなければならないので多少面倒でも纏めないほうがいいかも知れない。