- サブモジュールは コンポーネントベースの開発 に適しています。メインプロジェクトは固定バージョンに依存します。他のコンポーネントの（リポジトリ）。
親リポジトリでは参照のみを保持します（gitlinks、 インデックス内の特別なエントリ ）
リンクが常に外部リポジトリのHEADを指すようにしたい場合はどうすればよいですか。
サブモジュールを使って、サブモジュールのリモートリポジトリのブランチのHEADに従うことができます。
o git submodule add -b <branch> <repository> [<path>] . (to specify a branch to follow)
o git submodule update --remoteは、サブモジュールの内容を<repository>/<branch>から最新のHEADに更新します。デフォルトはOrigin/masterです。たとえ--remoteが使われていても、あなたのメインプロジェクトはサブモジュールのHEADのハッシュを追跡し続けます。
- サブツリーは システムベースの開発 のようなものです。あなたはどんな部分でも修正することができます。
この答えの例を見てください 。
サブモジュールはリンクです。
サブツリーはコピーです
概念の違いは次のとおりです。
gitサブモジュールを使用すると、通常、大きなリポジトリを小さなリポジトリに分割します。サブモジュールを参照する方法はmaven-styleです - あなたは他の（サブモジュール）リポジトリから単一のコミットを参照しています。サブモジュール内で変更が必要な場合は、サブモジュール内でコミット/プッシュを行い、次にメインリポジトリ内の新しいコミットを参照してから、メインリポジトリの変更された参照をコミット/プッシュする必要があります。そのようにしてあなたは完全な構築のために両方のリポジトリへのアクセス権を持たなければなりません。
git subtreeを使えば、履歴を含めてあなたのリポジトリに別のリポジトリを統合できます。そのため、統合した後のリポジトリのサイズはおそらく大きくなります（したがって、リポジトリを小さくするための戦略ではありません）。統合後は他のリポジトリへの接続はありません、そしてアップデートを入手したいのでなければアクセスする必要はありません。そのため、この戦略はコードと履歴の再利用に適しています - 私は個人的には使用しません。
サブモジュール
メインリポジトリをリモートにプッシュしてもサブモジュールのファイルがプッシュされない
サブツリー
メインリポジトリをリモートにプッシュするとサブツリーのファイルがプッシュされます