何时使用git子树？

git子树解决了什么问题？
何时以及为什么我应该使用该功能

我已经读到了。但我为什么不创建两个独立的存储库，而不是将两个不相关的存储库放在一个存储库中呢

本GitHub教程解释了这一点

我知道如何使用它，但不知道何时（用例）使用，为什么使用，以及它与什么有关。当我依赖于另一个项目或库时，我会使用子模块。
首先：我相信你的问题往往会得到非常固执己见的答案，可能会被认为是离题的。然而，我不喜欢这样的政策，我会把话题的边界向外推一点，所以我喜欢回答，希望其他人也这样做

在您所指的GitHub教程中，有一个链接提供了关于优缺点的观点：

比较子树合并与子模块

使用子树合并的好处是对存储库用户的管理负担较小。它与
较旧的（Git v1.5.2之前）客户端，之后就有了代码
克隆人

但是，如果使用子模块，则可以选择不传输子模块对象。这可能是子树合并的问题

此外，如果您对另一个项目进行了更改，那么如果您只使用子模块，则提交更改将更容易

以下是我基于上述观点的观点：

我经常和那些不是git普通用户的人（=提交者）一起工作，有些人仍然（并且将永远）在版本控制方面苦苦挣扎。教育他们如何使用子模块合并策略基本上是不可能的。它涉及到附加远程的概念，关于合并、分支，然后将其全部混合到一个工作流中。从上游拉动和向上游推动是一个两阶段的过程。因为分支对他们来说很难理解，所以这一切都是没有希望的

对于子模块来说，这仍然太复杂了（叹气），但更容易理解：这只是回购中的回购（他们熟悉层次结构），你可以像往常一样推拉

对于子模块工作流，提供简单的包装器脚本更容易

对于具有多个子回购的大型超级回购，选择不克隆某些子回购的数据是子模块的一个重要优势。我们可以根据工作要求和磁盘空间使用情况来限制这一点

访问控制可能不同。还没有出现这个问题，但是如果不同的回购协议需要不同的访问控制，有效地禁止一些用户使用某些子回购协议，我想知道使用子模块方法是否更容易实现

就我个人而言，我还没有决定自己该用什么。因此，我同意你的困惑：o]
当你在
git
的上下文中使用术语'subtree'时，你应该注意清楚地注意你在说什么，因为这里实际上有两个独立但相关的主题：

和

TL；博士
这两个与子树相关的概念都有效地允许您在一个数据库中管理多个存储库。与只有元数据存储在根存储库中的情况不同，它的形式是，并且您必须单独管理外部存储库

更多细节
git子树合并策略基本上是使用您引用的命令的更为手动的方法

git subtree是一个包装器shell脚本，用于简化更自然的语法。实际上，这仍然是contrib的一部分，并没有与通常的手册页完全集成到git中。而是沿着脚本存储

以下是使用信息：

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>]

名称
----
git子树-将子树合并在一起并将存储库拆分为子树
提要
--------
[诗句]
“git子树”添加-P
“git子树”添加-P
“git子树”pull-P
“git子树”push-P
“git子树”合并-P
“git子树”拆分-P[OPTIONS][]

当我打算写一篇自己的博客文章时，我遇到了很多关于子树的资源。如果我这样做，我会更新这篇文章，但现在这里有一些与手头问题相关的信息：

下面的相关部分可以找到您正在寻找的内容：

为什么使用子树而不是子模块？
原因有几个
您可能会发现
子树
更适合使用：


简单工作流的管理很容易
支持较旧版本的
git
（甚至在
v1.5.2
之前）
子项目的代码在超级项目的
克隆完成后立即可用
子树
不要求存储库的用户学习任何新内容，他们可以忽略您正在使用
子树
管理依赖项这一事实
子树
不会像
子模块
那样添加新的元数据文件（即。
.gitmodule
）
可以修改模块的内容，而无需
将依赖项的独立存储库副本放在其他地方

我认为这些缺点是可以接受的：


您必须了解新的合并策略（即
子树
）
为子项目提供代码返回
上游
，稍微复杂一些
不在提交中混合超级和子项目代码的责任在于您

我也同意这一点。我建议你看看这篇文章，因为它介绍了一些常见用法

您可能已经注意到，他还写了一篇后续文章，其中提到了这种方法所遗漏的一个重要细节

git子树
当前无法包含远程文件