问题描述
我试图弄清楚如何使用 git subtree（从我所看到的，子模块不是我想要的）以便同时处理两个 git 存储库，其中一个项目位于另一个内部。
就我而言，我正在使用 Unity 与我的主存储库一起工作。我决定将我的一些代码制作为一个包，所以我在文件夹 repositoryRoot/Packages/com.mypackage 中有另一个 git 存储库，这样我就可以在我以后的项目中使用这个包。
我不明白我应该使用哪些命令和 git 功能来分别提交到两个存储库，而且我想，只将对包的更改提交到包的存储库而不是主项目（还是我应该？）。
解决方法
首先，值得注意的是 git subtree 是 Git 世界中的一种 red-headed stepchild。过分依赖它可能是不明智的。
除此之外，子树和子模块之间存在巨大差异：
-
Git 子模块 只是获取一些现有 Git 存储库并使用它来自其他 Git 存储库的情况。为此，用户——我们称之为超级项目——只需列出路径名和 URL，Git 应该在其中运行
git clone来克隆 use-ee 或 子模块。此列表包含在由.gitmodules命令维护的git submodule文件中。克隆后，超级项目将偶尔cd进入子模块并运行git checkout --detach hash，其中要使用的 哈希 ID 存储在您在超级项目。这些被称为 gitlinks 并且 always 导致分离的 HEAD。这样做的结果是，当你在超级项目中工作时，你不会在子模块中做任何工作：超级项目只是调用一些已经存在的提交 在那个子模块中。如果你需要的提交不存在，你需要做的是找到或创建子模块存储库的克隆，在那里工作，创建你需要的提交，确保一切正常，把它推回你的超级项目的地方将从中克隆，以便 每个人 都存在提交，然后仅在 in 超级项目中进行新提交，该超级项目通过更新的 gitlink 引用此新子模块提交。
你工作的克隆，当你做必须提交一个新的子模块时，可以远离超级项目及其子模块，或者你可以只使用你已经使用的克隆在那里。请记住，超级项目 Git 将在某个时候深入到子模块 Git 中并进行分离的 HEAD 检出。 （如果您当时正在在子模块中工作，那可能会弄乱您的工作，因此请确保不会发生这种情况——即，不要让任何人运行任何 Git 命令在超级项目中——或者使用一个不同的克隆，或者一个添加的工作树，或者其他什么。如何确保超级项目 Git 不会把你搞砸并不重要，只要你做确保。）
-
子树，然而，被设计为或具有一个可重复的“从更大的、包含在内的外部 Git 存储库中提取这个新的 Git 存储库”的过程。
使这个过程可重复有点棘手，但 是可能的，前提是满足某些限制条件。特别是，我们知道任何给定提交的提交哈希 ID 绝对 100% 控制由该提交的完整内容控制，包括历史记录中的提交哈希 ID直到那个提交。只要提交的内容不改变，任何未来哈希ID的计算都将与过去相同内容的哈希ID计算完全匹配。 >
这意味着如果更大的存储库（“超级树”？我们需要一个名称：让我们称之为 R）只添加了新提交 ，并且我们对每个现有提交应用一个组成的过滤函数，过滤一些以前的R副本将产生一些新的子树输出S0。现在在 R 上重复相同的过程，添加新的提交，将产生一个超集 S1。此超集将包含 S0 所具有的所有相同提交，以及作为过滤新 R 提交的结果的任何新提交。由于那些只添加到R提交，新的S只提交添加到S 也一样。
为了实现这一点，R 中的任何提交都不能重新定位或以其他方式丢弃。 这样做会破坏 S 的超集属性.
但是：我们可以将 新 提交添加到一些提取的 Si，然后将这些提交导入回 R >?答案是有条件的。我们必须知道或找出在这个 S 中哪些提交实际上是新的，然后我们必须确保如果我们确实将它们添加到 R，我们会这样做因此，在过滤时，我们在此过程中放入的任何东西都会“过滤掉”。这可能很棘手：我们必须保留除 tree 对象之外的所有元数据。
如果出于任何原因需要更改此元数据，我们剩下的选择是将这个特定的 Si 视为自己的红头发继子。我们导入新提交，然后将 Si 声明为 persona non grata 并生成替换 Si+1 并丢弃所有对 Si 的使用。
在实践中，这些规则可以起作用，git subtree split 和 git subtree merge 可以处理过滤（创建一些 S）并返回 -导入更新。但是这些可能会出错的小陷阱确实存在，而且 git subtree 在 Git 邮件列表中并没有得到太多关注。子模块的东西得到了更多的维护。它通常更烦人，并且有自己的锋利边缘，但它绝对得到了更好的支持。
（旁注：我生来就是ginger。瞧，几个世纪后，我现在几乎只是灰色的，而且我从来都不是继子。?）