我有一个相当不寻常的问题:我在同一台机器上进行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版本放在不同的分支上，尽管我真的希望它们放在同一个分支上。尽管如此，它还是在发挥作用，并且是一个不同寻常的工作树拯救世界的例子。

我正在使用git工作树进行机器学习开发。

我有一个主要的功能代码，然后我想拆分不同实验的分支(不同的算法和不同的超参数)。Git工作树允许我将DVC与针对不同算法的不同版本的代码集成在一起。在运行所有的培训工作后，我评估最终的指标，并合并以掌握最好的分支/模型。

一个明显的用途是同时比较不同版本的行为(而不是来源)——例如，一个网站的不同版本或仅仅是一个网页。

我在当地试过。

创建目录page1。 在里面创建目录SRC和git init它。 在SRC中创建带有少量内容的page1.html并提交。 $ git分支ver0 $ git工作树添加../ V0 ver0 在SRC master中添加更多文本到page1.html并提交。 $ git分支sty1 在sty1分支中编辑page1.html(添加一些独特的CSS样式)并添加提交。 $ git工作树添加../ S1 sty1

您现在可以使用网页浏览器同时打开和查看这3个版本:

.\page1\src\page1.html //任何git当前的内容 .\page1\V0\page1.html //初始版本 \page1\S1\page1.html //实验风格的版本

我能看出这东西的用处。

如果您有一个运行很长时间的测试套件，想象一下，当您启动它时，它会有效地阻塞工作副本，直到测试完成。在这些测试期间切换分支会以一种难以理解的方式破坏它们。

所以有了git-worktree，我可以为另一个分支推出第二个想法。

另外，当我切换到其他分支做一些快速调查时，我的IDE认为很多文件突然发生了变化，并将索引所有这些更改，只是在我切换回来时必须重新索引它们。

第三个用例是使用git-diff以外的其他工具(如普通的diff)在两个目录之间(而不是两个分支)进行文件比较。

在我的新项目中，我创建了一个功能。 但一些规格失败了。为了与master比较结果，我创建了一个工作树repo。我在运行代码中一步一步地比较结果，直到了解哪里出了问题。

我最初是在想这些花哨的工作树可以用来做什么时偶然发现这个问题的。从那以后，我将它们整合到我的工作流程中，尽管我最初持怀疑态度，但我逐渐发现它们相当有用。

我在一个相当大的代码库上工作，这需要相当长的时间来编译。我通常在我的机器上有当前的开发分支，以及我当前正在工作的特性分支，再加上主分支，它代表了活动系统的当前状态。

对我来说，最大的好处之一显然是，每次切换分支(即工作树)时，我都不必重新编译整个东西。一个很好的副作用是，我可以去开发工作树，在那里做一些事情，为我当前的特性分支更改目录，然后重新建立它，而不需要先拉。