gitサブモジュールが達成する効果は、まさにあなたが望むものです。複数のプロジェクトが依存する共通コードの本体であり、すべての依存プロジェクト間で共有される共通コードへの修正が含まれています。サブモジュールは、共有コードの履歴を分離することで効果を実現しますが、それは単なるメカニズムであり、一度それを見ると、それが自然に正しい解決策であることがわかります。
サブモジュールコマンド自体は、いくつかの厄介なハウスキーピングの詳細を追跡するために存在します（通常、rm -rf *リポジトリ内でコミットされた状態を失うことはありませんが、ネストされたリポジトリではそうではないため、コマンドは通常、サブモジュール.git dirsを持ち上げます;そのようなもの）、ただし、サブモジュール自体は、独自の履歴を持つネストされたリポジトリにすぎません。それにcdすると、gitコマンドはそれが何かのサブモジュールであることさえ知りません。なぜなら、サブモジュールであるということは、リポジトリ自体に固有のものではなく、リポジトリがどのように使用されているかということです。
git init projectA
cd projectA
touch A # now there's a file at the projectA root,
# but the projectA repo doesn't know about it
echo 'this content is in file "A" at the projectA root'> A
git add A # content recorded, the index points to it
git commit -m'A' # now projectA repo has a permanent record of the indexed state
git init projectInner # now there's an entire repo at the projectA root,
# but the projectA repo doesn't know about it
cd projectInner
echo "Inner content" > Inner # a file at the inner repo, no repo knows about it
git add Inner # content recorded, the inner repo's index records it
git commit -mInner # the inner repo has a permanent record
cd ..
git add projectInner # now the projectA repo knows about the inner, the content is recorded ...
git commit -mInner # and now the projectA repo has a permanent record
git add実際のリポジトリを作成するということは、ファイルやディレクトリを追加する場合と同じように、現在の状態を記録することを意味しますが、ファイルの記録された状態はその内容全体であり、ディレクトリの記録された状態はそのすべての再帰的な状態です（追跡または無視されない）コンテンツの場合、レポの記録された状態は、単にそのHEADコミットのSHAであり、他のすべてはそのレポ自体にすでに記録されています。
ここでのペイロードは、gitサブモジュールが単にネストされたリポジトリであるということです。ネストされたリポジトリは非常に便利なものになる可能性があります。gitの他の部分と同様に、サブモジュールコマンドが実際に実行していることは非常に単純です。明らかに複雑なのは、非常に便利なさまざまな状況で最も便利なものを実装することです。