git 工作树与 "clone --reference"

Question

使用 git worktrees 与使用 --reference 维护多个克隆的优缺点是什么？旗帜？我正在考虑的主要场景是，当开发人员需要在磁盘上为旧版本(release/1.0、release/2.0、release/3.0)维护多个 git 存储库时，因为在单个 git 存储库上切换分支和重建的成本很高。

使用工作树，开发人员可以拥有一个 repo 的克隆，并且可以使用 cd /opt/main/ 将任何旧版本创建为 repo 的工作树。 , git worktree add /opt/old_release_1 release/1.0 .使用引用克隆，开发者在某处维护一个主克隆，并使用 cd /opt/old_release_1 , git clone --reference /opt/main/.git ssh://git@github.com/myrepo.git为旧版本创建克隆存储库。

似乎他们都可以实现相同的目标。在速度、磁盘空间......其他方面，两者是否有优势？

Answer 1

他们都有一些重要的问题，但使用 git worktree可能会是你最好的选择。

一个克隆，我们称之为依赖后克隆的 AD，由 --reference local-path 制作但没有 --dissociate使用来自 local-path 的对象.通过“对象”，我的意思是字面 Git 对象(松散存储和/或在包文件中)。另一个 Git 存储库——在 local-path 中的那个— 不知道 AD 正在使用这些。

我们称基本克隆为 BC。现在，假设在 BC 中发生了一些事情，因此不再需要某个对象，例如删除分支名称或远程跟踪名称。此时，git gc在 BC 中运行可能会垃圾收集并删除对象。

如果您现在切换到 AD 克隆并运行各种 Git 操作，它们可能会由于删除的对象而失败。问题是旧的 BC 克隆不知道新的 AD 克隆依赖于它。

请注意，AD 中嵌入了 BC 的路径名。如果您移动 BC，则必须编辑 .git/objects/info/alternates AD 中的文件。

用 git worktree add 制作的工作树还使用来自原始克隆的对象。我们仍将原始克隆称为 BC，添加的工作树仅称为 Wb。与上面的 BC/AD 设置有两个主要区别:

每个新的工作树 Wb 都使用整个 .git BC 的目录。

BC 存储库记录了每个 Wb 的路径，因此它知道每个 Wb。您不会遇到对象意外消失的问题。

然而，由于 BC 记录了每个 Wb 并且所有分支名称实际上都位于 BC 内部，因此存在一个约束:在 BC 中 check out 的任何分支都不能在任何 Wb 中 check out 。此外，Wb1 必须“开启”(如 git status 说 on branch ... )与 Wb2 不同的分支，依此类推。 (您可以处于“分离的 HEAD”模式，即根本不在任何分支上，在任何或所有 BC 和每个 Wb 中。)

由于 BC 记录每个 Wb 路径(反之亦然)，如果要移动这些存储库中的任何一个，则必须调整路径。