git worktrees 与“clone --reference”

Question

使用 git worktrees 与使用 flag 维护多个克隆相比有何优缺点--reference？我考虑的主要场景是，开发人员需要在磁盘上维护旧版本的多个 git 存储库（release/1.0、release/2.0、release/3.0），因为在单个 git 存储库上切换分支和重建成本高昂。

cd /opt/main/使用工作树，开发人员可以拥有存储库的单个克隆，并且可以使用,将任何旧版本创建为存储库的工作树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可能是您最好的选择。

\n\n

\n

• 一个克隆，让我们将此AD称为依赖后克隆，使用但 不使用来自. 我所说的“对象”是指字面上的 Git 对象（松散存储和/或存储在包文件中）。另一个 Git 存储库\xe2\x80\x94（\xe2\x80\x94 中的那个）不知道AD正在使用这些。--reference local-path --dissociatelocal-pathlocal-path

  \n\n

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

  \n\n

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

  \n\n

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

\n

• 用 制作的工作树git worktree add也使用原始克隆中的对象。我们仍然将原始克隆称为BC，添加的工作树称为W _b。与上面的 BC/AD 设置有两个主要区别：

  \n\n
  \n

  • 每个新的工作树W _b实际上都使用BC中的整个.git目录。

  \n

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

  \n

  • 然而，由于BC记录了每个W _b并且所有分支名称实际上都存在于BC本身内部，因此存在一个约束：在BC中签出的任何分支都不能在任何W _b中签出。此外，W _b1必须位于与W _b2不同的分支“上”（如git status所示） ，依此类推。（您可以处于“分离 HEAD”模式，即根本不在任何分支上、在任何或所有BC和每个W _b中。）on branch ...

  \n
  \n\n

  由于BC记录了每个W _b路径（反之亦然），因此如果要移动这些存储库中的任何一个，则必须调整路径。

\n

\n