使用git worktrees与使用--reference标志维护多个克隆的优缺点是什么？我正在考虑的主要场景是开发人员需要在磁盘上为旧版本（版本/ 1.0，版本/ 2.0，版本/ 3.0）维护多个git存储库，因为在单个git repo上切换分支并重建将会很昂贵。
使用工作树，开发人员可以拥有一个repo的单个克隆，并且可以使用cd /opt/main/，git worktree add /opt/old_release_1 release/1.0创建任何旧版本作为repo的工作树。使用引用克隆，开发人员在某处维护主克隆，并使用cd /opt/old_release_1，git clone --reference /opt/main/.git ssh://git@github.com/myrepo.git为旧版本创建克隆存储库。
看起来他们都可以实现相同的目标。在速度，磁盘空间......其他方面，它们对另一方有好处吗？
答案 0 :(得分：2)
他们都有一些重要的问题，但使用git worktree可能是你最好的选择。
克隆，让我们将此 AD 称为后依赖性克隆，使用 --reference local-path进行，但不使用 { {1}}使用 --dissociate 中的对象。 “对象”是指文字Git对象（松散存储和/或包文件）。另一个Git存储库 - local-path 中的存储库 - 不知道 AD 正在使用这些存储库。
让我们调用基本克隆 BC 。现在，假设在 BC 中发生了某些事情，因此不再需要某个对象，例如删除分支名称或远程跟踪名称。此时， BC 中的local-path运行可能会垃圾收集并删除该对象。
如果您现在切换到 AD 克隆并运行各种Git操作，它们可能会因删除的对象而失败。问题是较旧的 BC 克隆不知道较新的 AD 克隆依赖于它。
请注意， AD 中嵌入了 BC 的路径名。如果您移动 BC ，则必须编辑 AD 中的git gc文件。
使用.git/objects/info/alternates制作的工作树也使用原始克隆中的对象。让我们仍然调用原始克隆 BC ，添加的工作树名为 W b 。与上面的BC / AD设置有两个主要区别：
每个新的工作树 W b 字面上使用 BC 中的整个git worktree add目录。
BC 存储库记录每个 W b 的路径，因此它知道每个 W b'/子> 的。你不会遇到意外消失的问题。
但是，由于 BC 记录每个 W b ，所有分支名称实际上都在 BC 本身，存在约束：在 BC 中签出的任何分支都无法在任何 W b 中检出。此外， W b1 必须“开启”（如.git所述git status）与 W b2不同的分支 ，依此类推。 （您可以处于“分离的HEAD”模式，即，根本不在任何分支上，在任何或所有 BC 中，并且每个 W b ）。
由于 BC 记录每个 W b 路径（反之亦然），如果你想移动任何这些存储库，您必须调整路径。