我读了Github's post on git-worktree。他们写道：
当用户在
feature报告高紧急性错误时，假设您正在名为master的分支上的Git存储库中工作。首先，您创建一个链接的工作树，其中包含一个新的分支hotfix，相对于master [...]签出。您可以修复错误，推送修补程序，并创建一个拉取请求。
当我在一个名为feature的分支上工作并报告master中的一些高紧急错误时，我通常会隐藏我正在处理的任何内容并创建一个新的分支。当我完成后，我可以继续工作。这是一个非常简单的模型，我已经这样做多年了。
另一方面，使用git-worktree有其自身的局限性：
例如，不允许同时在两个链接的工作树中检出相同的分支，因为这将允许在一个工作树中提交的更改使另一个工作树不同步。 / p>
为什么我会为已经解决的问题选择更复杂的工作流程？
是否有任何关于git-worktree事先无法完成的事情并证明了这一全新的复杂功能？
答案 0 :(得分：124)
对我来说，git worktree是很长一段时间以来最大的改进。我正在从事企业软件开发。在那里，你必须维护旧版本，就像你3年前发布的版本一样。当然，每个版本都有一个分支，以便您可以轻松切换到它并修复错误。但是，切换是昂贵的，因为在此期间您完全重新构建了存储库并可能构建系统。如果你切换，你的IDE会疯狂地试图调整项目设置。
使用worktree，您可以避免不断重新配置。使用worktree检查单独文件夹中的旧分支。对于每个分支，您都有一个独立的IDE项目。
当然，这可以通过多次克隆回购来完成，这是迄今为止我的做法。然而，这也意味着浪费硬盘空间，更糟糕的是需要多次从回购中获取相同的更改。
现在，唯一缺少的部分是适用于Windows的官方git 2.5版本，但希望new git for windows即将发布： - ）
答案 1 :(得分：59)
我可以看到一些用途。
如果你有一个运行了很长时间的测试套件，想象几个小时，并启动它，它会有效地阻止该工作副本，直到测试完成。在这些测试期间切换分支会以难以理解的方式打破它们。
所以使用git-worktree我可以为另一个在那里工作的分支启动第二个想法。
此外，当我切换到其他分支进行快速调查时，我的IDE认为很多文件突然改变并将索引所有这些更改，只是为了在我切换回来时再次重新索引它们
第三个用例是使用git-diff之外的其他工具进行文件比较，如同普通diff，在两个目录之间，而不是两个分支。
答案 2 :(得分：51)
一个显而易见的用途是同时比较不同版本的行为（非来源） - 例如网站的不同版本或仅仅是网页。
我在当地尝试过这个。
创建目录page1。
在里面创建目录src和git init。
在src创建page1.html并添加一些内容并提交。
$ git branch ver0
$ git worktree add ../V0 ver0
src master中向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 //实验风格的版本
答案 3 :(得分：23)
您可能需要同时在文件系统中需要/需要多个工作树。
操纵签出的文件，而需要在其他地方进行更改（例如编译/测试）
通过常规差异工具区分文件
在合并冲突期间，我经常希望浏览源代码，因为它位于源端，而解决文件中的冲突。
如果你需要来回切换，浪费时间结账并重新检查你不需要多个工作树。
通过git stashing在分支之间切换心理上下文的心理成本并不是真正可衡量的。有些人发现，通过简单地打开来自不同目录的文件，存在不存在的心理成本。
有些人问“为什么不做多个本地克隆”。确实，使用“--local”标志，您不必担心额外的磁盘空间使用情况。这个（或类似的想法）是我到目前为止所做的。链接工作树对本地克隆的功能优势是：
对于本地克隆，您的额外工作树（位于本地克隆中）根本无法访问原点或上游分支。克隆中的“起源”与第一个克隆中的“起源”不同。
git log @{u}..或git diff origin/feature/other-feature可能会非常有用，这些要么不再可能，要么更难。通过各种工作方式，本地克隆在技术上可以实现这些想法，但您可以通过链接的工作树完成更好和/或更简单的工作。您可以在工作树之间共享引用。如果您想比较或借用其他本地分支的更改，现在就可以。
答案 4 :(得分：9)
tl; dr：无论出于何种原因，只要您想同时检出两棵工作树，git-worktree就是一种快速且节省空间的方法。
如果您创建另一个工作树，则repo的大多数部分（即.git）将被共享，这意味着如果您在一个工作树中创建分支或获取数据，它也可以从任何工作树中访问你有其他工作树。假设你想在分支foo上运行测试套件而不必将其推送到某个地方来克隆它，并且你想避免在本地克隆你的repo的麻烦，使用git-worktree是创建一个新的结帐的好方法某个国家在一个单独的地方，暂时或永久。就像克隆一样，完成它之后你需要做的就是删除它，并且在一段时间之后对它的引用将被垃圾收集。
答案 5 :(得分：6)
在想知道这些花哨的工作树可以用于什么之后，我最初偶然发现了这个问题。从那时起，我已将它们整合到我的工作流程中，尽管我最初持怀疑态度，但我发现它们非常有用。
我在一个相当大的代码库上工作，这需要相当长的时间来编译。我通常在我的机器上有当前的开发分支以及我正在处理的功能分支以及主分支，它代表了实时系统的当前状态。
对我来说最大的好处之一显然是我每次切换分支时都不必重新编译整个事物（即工作树）。一个很好的副作用是我可以进入开发工作区，在那里做一些事情，将目录更改为我当前功能分支的工作树，然后在不必先拉动的情况下重新设置它。
答案 6 :(得分：3)
我有一个相当不寻常的一个：我在同一台机器上进行Windows和Linux开发。我的Windows框中有一个运行Linux的VirtualBox。 VirtualBox安装了一些Windows目录，并直接在Linux机器内部使用它们。这让我可以使用Windows来管理文件，但是可以在Linux中构建。这是一个跨平台项目，因此它在同一目录结构的Windows和Linux上构建。
问题是Linux和Windows构建系统在同一目录中使用时会相互崩溃;有一些复杂的构建步骤用于下载使用相同目录名的库等。构建系统的Windows版本下载特定于Windows的库，构建系统的Linux版本下载特定于Linux的库。
在理想的世界中，构建系统将被修改，以便Windows＆amp; Linux可以在目录中共存，但是目前，问题正在通过工作树来解决。 “Linux”文件夹可以生成特定于Linux的构建工件，“Windows”文件夹可以生成特定于Windows的构建工件。虽然这不是一个理想的解决方案，但它在等待构建系统错误得到解决时是一个很好的权宜之计。
不可否认，工作树不是为此设计的;我必须将Windows版本和Linux版本保留在不同的分支上，即使我真的希望它们位于同一分支上。不过，它正在完成这项工作，并且是一个有点非传统的工作树节省时间的案例。
答案 7 :(得分：1)
在我的新项目中，我创建了一个功能。
但有些规格失败了。要将结果与master进行比较，我创建了work-tree个回购。我在运行代码中逐步比较结果，直到了解出了什么问题。
答案 8 :(得分：1)
我绝对喜欢，并且每个人都应该使用 beforeEach(async () => {
await waitFor(() => render(<App />));
});
的最常见用例是，在仍然在主工作树中进行更改的同时，检查队友的请求请求。 ?
答案 9 :(得分：0)
我正在使用git worktree进行机器学习开发。
我有一个主要的功能代码，然后我想拆分不同实验的分支（不同算法和不同超参数）。 git worktree使我可以将dvc与专门针对不同算法的不同版本的代码集成在一起。完成所有培训工作后，我评估最终指标并合并以掌握最佳分支/模型。