ひとつの製品もしくはサービスが
- Javaで書かれたサーバ
- C++で書かれたクライアント
のように複数のソースプロジェクトに分かれていることはよくある構成かと思います。
クロスプラットフォーム開発環境を使っていなければ、クライアントがさらにWin, Mac, iOS, Androidとたくさんのプロジェクトに分かれているかもしれません。
さてそれをGitで版管理する場合、何本のリポジトリにしますかというのに迷います。
1ソースプロジェクト＝1リポジトリ
冒頭の2プロジェクトならリポジトリは2本作る方法。
（1リポジトリ内に共通祖先を持たない2ブランチ作る、というのもコミットツリーの姿は同じなのでこれに含まれるでしょう）
利点：
- 各モジュールの開発メンバーにとって関心領域外のソースを触らずに済む
- herokuのような、リポジトリルート＝ソースルートを前提としたシステムと相性が良い
- 各モジュールがビルドに別々のマシン環境を要求する場合（MFCアプリもiOSアプリもあるとか）、Jenkinsを別々に立ててそれぞれのリポジトリを監視させれば良く、単純
1製品＝1リポジトリ
Server, Clientというディレクトリ内にサーバ、クライアントそれぞれのソースを置くことにし、全体を一本のリポジトリで管理する方法。
利点：
- リリースタグを全モジュールまとめて打てる
- プロトコル仕様変更のようなモジュールにまたがった変更を1コミットにまとめられる
- さらにDocumentsディレクトリも作って仕様書類の変更もその1コミットに含めてしまったり
- いざとなれば【1ソースプロジェクト＝1リポジトリ】形式への変換もコマンド一発でできる
各ソースプロジェクトリポジトリも、全部まとめた製品リポジトリも作ってサブツリーマージ戦略
上記二つのいいとこ取り？
たぶん運用手順としては、ソースプロジェクトのトピックブランチを製品リポジトリの側でmasterにマージしてから、製品masterをソースプロジェクトmasterへプッシュ、などという流れになるんでしょうか。
欠点：
- ややこしい
ノウハウお聞かせください
いつもこうやっている、ああやったら後悔した、ああやるのが標準的なんじゃないか、などコメントお待ちしております。