マスターリポジトリのサブモジュールとしてリポジトリマイクロサービスのグループを管理することは良い考えですか？
これを書いている時点で、より大きなシステムを構築するために4つのマイクロサービスが相互運用しているとしましょう。すべてのマイクロサービスには独自のリポジトリがあります。
私が考えているのは、子マイクロサービスをグループ化し、それらをgitサブモジュールとして追加する親リポジトリがあると便利だということです。
したがって、開発者が開発環境を次のように設定する必要がある場合：systemAをms1、ms2、m3で作成systembをms2、ms3、ms5で作成
システムリポジトリのクローンを作成するだけです（すでにms依存関係にリンクしています）
または、新しいシステムを構築する必要がある場合は、gitサブモジュールms依存関係にリンクする新しい親リポジトリを作成します
基本的に、親リポジトリにはサブモジュールへのリンクしか含まれません（現時点でさらに必要になるかどうかはわかりません。）
確かに、異なるシステム間でms開発を共有するという問題に直面するでしょう。だから、おそらくそれは子供レポで異なるマスターブランチを使用して解決されるでしょう（すべての親の生産システムに1つ）
この習慣についてどう思いますか？それは良い考えですか？サブモジュールでの作業はトリッキーになる可能性がありますか？
- ワークフローに従うのが難しい
- 歴史が雑然としている
- 非gitエキスパートの直感的でない動作
- 簡単に壊れる（上のリンクのセクション「サブモジュールは簡単に壊れ、サブモジュールはひどく壊れる」を参照）
私たちはあなたが説明するような何かのためにそれらを使ってきました、そしてそれは今地獄です。コードの一部を変更し、それがコミットしやすいものか、サブモジュールにプッシュするためにいくつかのアクロバットが必要なものか、そして親レポジトリの参照を更新してプッシュするかどうかわからないそれ。時々、私たち一人一人が何が起こっているのか、そしてその理由を理解しようと何時間も費やします：
a）サブモジュールの更新（--recursive？ --remote？）更新されません
b）gitは変更について不平を言うが、それらをコミットしてもコミットされない
c）ブランチに行き詰まり、サブモジュールの変更を解決するまで何もできない（スタッシングは機能せず、変更を無視する他のトリックもない）
さて、認めます-私たちの誰もgitの専門家ではありません。おそらく私たちは時々何か間違ったことをしています。ただし、ほとんどの場合、rebaseなどの高度なgit機能を使用しても問題はありません。
私はあなたがサブモジュール内にサブモジュールを持っているときに何が起こるかについて私の怒りを続けません...
より良いソリューションのように見えるのは、内部パッケージマネージャーを作成することです（この場合、社内にNuGetサーバーがあります）。
正直に言うと、サブモジュールがうまく機能しているように見えるプロジェクトがあります（例 Qt ）。