当您在 git 的上下文中使用术语 'subtree' 时，应注意明确指出您在说什么，因为这里实际上有两个独立但相关的主题：
git-subtree 和 git subtree merge strategy。
TL;DR
这两个子树相关的概念都可以有效地让您同时管理多个存储库。与git-submodule 相比，只有元数据以.gitmodules 的形式存储在根存储库中，并且您必须单独管理外部存储库。
更多详情
git subtree merge strategy基本上是使用您引用的命令的更手动的方法。
git-subtree 是一个包装外壳脚本，以促进更自然的语法。这实际上仍然是contrib 的一部分，并没有通过通常的手册页完全集成到 git 中。 documentation 与脚本一起存储。
这里是使用信息：
NAME
----
git-subtree - Merge subtrees together and split repository into subtrees
SYNOPSIS
--------
[verse]
'git subtree' add -P <prefix> <commit>
'git subtree' add -P <prefix> <repository> <ref>
'git subtree' pull -P <prefix> <repository> <ref>
'git subtree' push -P <prefix> <repository> <ref>
'git subtree' merge -P <prefix> <commit>
'git subtree' split -P <prefix> [OPTIONS] [<commit>]
我遇到了很多关于子树主题的资源，因为我正计划写一篇自己的博客文章。如果我这样做了，我会更新这篇文章，但现在这里有一些与手头问题相关的信息：
您可以在this Atlassian blogNicola Paolucci 上找到您正在寻找的大部分内容：
为什么使用子树而不是子模块？
有几个原因
你可能会发现subtree 更好用：
- 简单工作流的管理很容易。
- 支持旧版本的
git（甚至早于v1.5.2）。
- 子项目的代码在超级项目的
clone完成后立即可用。
-
subtree 不需要您的存储库的用户学习任何新内容，他们可以忽略您正在使用 subtree 管理依赖项这一事实。
-
subtree 不会像 submodules 那样添加新的元数据文件（即
.gitmodule)。
- 可以修改模块的内容而无需使用
其他地方的依赖项的单独存储库副本。
我认为缺点是可以接受的：
- 您必须了解新的合并策略（即
subtree）。
- 为子项目贡献代码回
upstream 稍微复杂一些。
- 在提交中不混合超级项目和子项目代码的责任在于您。
我也同意其中的大部分内容。我建议您查看这篇文章，因为它介绍了一些常见用法。
您可能已经注意到，他还写了一个跟进here，其中他提到了这种方法遗漏的一个重要细节......
git-subtree 目前无法包含遥控器！
这种短视可能是由于人们在处理子树时经常手动添加远程，但这也没有存储在 git 中。作者详细介绍了他编写的一个补丁，用于将此元数据添加到git-subtree 已经生成的提交中。在它进入官方 git 主线之前，您可以通过修改提交消息或将其存储在另一个提交中来做类似的事情。
我还发现this blog post 也非常有用。作者添加了他称为git-stree 的第三个子树方法。这篇文章值得一读，因为他在比较这三种方法方面做得很好。他对自己喜欢什么和不喜欢什么给出了个人意见，并解释了他为什么要创建第三种方法。
附加功能
结束思想
本主题既展示了git 的强大功能，也展示了当某个功能未达到目标时可能发生的分割。
我个人对git-submodule 产生了厌恶，因为我发现贡献者更难以理解。我也更喜欢在我的项目中管理我的所有依赖项，以促进易于重现的环境，而无需尝试管理多个存储库。然而，git-submodule 目前更为人所知，因此了解它显然是件好事，这取决于可能会影响您决定的受众。