我将使用git-worktree做什么？

我在git-worktree上阅读了Github的帖子。他们写：

假设您正在一个名为的分支上的Git存储库中工作feature，当用户报告中存在一个紧急问题时master。首先，您将创建一个具有新分支，的链接工作树，hotfix相对于master […]检出。您可以修复错误，推送修补程序并创建请求请求。

当我在一个名为feature的分支上工作并且报告了master中的一些紧急问题时，我通常会把我正在从事的工作藏起来并创建一个新的分支。完成后，我可以继续工作。这是一个非常简单的模型，多年来我一直在那样工作。

另一方面，使用git-worktree有其自身的局限性：

例如，不允许在两个链接的工作树中同时检出同一分支，因为这将允许在一个工作树中提交的更改使另一个工作树不同步。

为什么要为已经解决的问题选择更复杂的工作流程？

是否有任何事git-worktree无法做，并且证明了这个全新的，复杂的功能？

对我来说，git worktree是长期以来最大的改进。我正在从事企业软件开发。在那里，通常必须维护3年前发布的旧版本。当然，每个版本都有一个分支，以便您可以轻松切换到该分支并修复错误。但是，切换是昂贵的，因为与此同时，您已完全重组了存储库并可能构建了系统。如果切换，IDE将运行疯狂以尝试调整项目设置。

使用工作树，您可以避免不断进行重新配置。使用工作树在单独的文件夹中检出那些旧分支。对于每个分支，您都有一个独立的IDE项目。

当然，过去可以通过多次克隆回购库来完成此操作，到目前为止，这是我的方法。但是，这也意味着浪费hardrive空间，更糟的是需要多次从仓库中获取相同的更改。

我可以看到一些用途。

如果您的测试套件可以长时间运行，请想象几个小时，然后启动它，它会有效地阻止该工作副本，直到测试完成。在这些测试期间切换分支将以难以理解的方式破坏它们。

因此，git-worktree有了这个想法，我可以为另一个分支在那里开展工作提出第二个想法。

另外，当我切换到其他分支进行快速调查时，我的IDE认为很多文件突然更改，并将为所有这些更改编制索引，只是当我切换回去时必须再次为其重新编制索引。

第三种用例是使用两个目录之间的git-diff常规比较工具，diff而不是两个分支来进行文件比较。

一个明显的用途是同时比较不同版本（例如网站的不同版本或只是网页）的行为（而非来源）。

我在本地尝试过。

• 创建目录page1。

• 在里面创建目录src和git init它。

• 在src创建page1.html一个小的内容和提交。

• $ git branch ver0

• $ git worktree add ../V0 ver0

• 在srcmaster中添加更多文本page1.html并提交。

• $ git branch sty1

• page1.html在sty1分支中进行编辑（添加一些独特的CSS样式）并添加提交。

• $ git worktree add ../S1 sty1

现在，您可以使用网络浏览器同时打开和查看这三个版本：

• ..\page1\src\page1.html // git的当前值

• ..\page1\V0\page1.html //初始版本

• ..\page1\S1\page1.html //实验样式的版本

1. 有正当的理由为什么您可能想要/需要一次在文件系统中使用多个工作树。

   • 操纵签出的文件，而无需进行更改别的地方（如编译/测试）

   • 通过普通的差异工具差异文件

   • 在合并冲突期间，我经常想在源代码中浏览源代码，同时解决文件中的冲突。

   • 如果您需要进行很多次来回切换，则浪费了时间签出和重新签出不需要使用多个工作树的时间。

   • 通过git隐藏在分支之间进行精神上下文切换所花费的精神成本实际上无法衡量。有些人发现，通过简单地打开其他目录中的文件，进行隐藏会带来精神上的损失。

2. 有人问“为什么不做多个本地克隆”。的确，有了“ --local”标志，您不必担心额外的磁盘空间使用情况。这是我到目前为止所做的（或类似的想法）。与本地克隆相比，链接的工作树的功能优势是：

   1. 使用本地克隆，您的额外工作树（位于本地克隆中）根本无法访问原始分支或上游分支。克隆中的“来源”将与第一个克隆中的“来源”不同。

      • 运行git log @{u}..或git diff origin/feature/other-feature可能会非常有帮助，这些不再可能或更困难。这些想法在技术上可以通过各种各样的工作机制在本地克隆中实现，但是通过链接的工作树，您可以做的每个解决方法都可以做得更好和/或更简单。

   2. 您可以在工作树之间共享引用。如果您想比较或借用其他本地分支机构的更改，现在可以。

tl; dr：任何时候无论出于何种原因想要同时注销两个工作树，这git-worktree都是一种快速且节省空间的方法。

如果创建另一个.git工作树，则仓库的大部分（即）将被共享，这意味着如果您在一个工作树中创建分支或获取数据时，也可以从您拥有的任何其他工作树中访问它。假设您要在分支foo上运行测试套件，而不必将其推送到某个位置以对其进行克隆，并且您想避免在本地克隆您的存储库的麻烦，使用这git-worktree是一种不错的方法，它可以仅在分支中创建某些状态的新签出暂时或永久的单独地点。就像克隆一样，完成克隆后所需要做的就是删除它，并且对其的引用将在一段时间后被垃圾回收。

我最初不知道这些花哨的工作树可以用来做什么之后，就偶然发现了这个问题。从那时起，我便将它们集成到我的工作流程中，尽管最初抱有怀疑，但我还是发现它们非常有用。

我在一个相当大的代码库上工作，这需要花费一些时间来编译。我通常在计算机上拥有当前的开发分支以及当前正在处理的功能分支以及master分支，该分支代表实时系统的当前状态。

对我来说，最大的好处之一就是，我不必在每次切换分支（即工作树）时都重新编译整个过程。一个不错的副作用是，我可以转到开发工作树，在其中进行操作，将目录更改为当前功能分支的工作树，然后对其进行基础调整而不必先拉。

我有一个非常不寻常的例子：我在同一台机器上进行Windows和Linux开发。我在Windows框内有一个运行Linux的VirtualBox。VirtualBox会挂载一些Windows目录，并直接在Linux机器内部使用它们。这使我可以使用Windows来管理文件，但可以在Linux中构建文件。这是一个跨平台项目，因此它在Windows和Linux上都基于相同的目录结构构建。

问题在于，Linux和Windows构建系统在同一目录中使用时会崩溃。有一些使用相同目录名下载库等复杂的构建步骤。Windows版本的构建系统下载Windows特定的库，Linux版本的构建系统下载Linux特定的库。

在理想情况下，将修改构建系统，以便Windows和Linux可以在目录中共存，但目前，问题是通过工作树解决的。“ Linux”文件夹可以生成特定于Linux的构建工件，而“ Windows”文件夹可以生成特定于Windows的构建工件。尽管这不是理想的解决方案，但在等待解决构建系统错误时，这是​​一个不错的选择。

诚然，工作树并不是为此目的而设计的。我必须将Windows版本和Linux版本保留在单独的分支中，即使我真的希望它们位于同一分支中。尽管如此，它正在完成工作，并且是工作树节省时间的一种非常规案例。

在我的新项目中，我创建了一个功能。但是某些规格失败了。为了比较结果，master我创建了一个work-tree仓库。我在运行代码中逐步比较了结果，直到了解出了什么问题。

我正在git worktree用于机器学习开发。

我有一个主要的功能代码，然后我想拆分不同实验的分支（不同的算法和不同的超参数）。git worktree使我可以将dvc与针对不同算法的代码的不同版本集成在一起。完成所有培训工作后，我评估最终指标并合并以掌握最佳分支/模型。