我会用什么git-worktree？

我读了github的git-worktree的文章。他们写：

假设你在一个叫做feature的分支上的Git仓库中工作，那么当用户报告master一个高度紧急的bug时。首先你创build一个带有一个新分支的链接工作树， hotfix ，检出相对于主[…]您可以修复错误，推动修补程序，并创build一个拉请求。

当我在一个叫做feature的分支上工作，并且报告了master的一些高度紧迫的bug时，我通常会把我正在工作的任何东西都藏起来，并创build一个新的分支。当我完成后，我可以继续工作。这是一个非常简单的模式，我一直这样工作多年。

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

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

为什么我会为已经解决的问题select更复杂的工作stream程？

是否有任何事先不能做的git-worktree ，这certificate了这个全新的复杂function？

对我来说，git worktree是长久以来最大的改进。我正在从事企业软件开发工作。在那里，你必须维护3年前发布的旧版本。当然，每个版本都有一个分支，以便您可以轻松地切换到它并修复一个错误。但是，交换是昂贵的，因为在此期间，您完全重新构build了存储库并可能构build系统。如果切换，IDE将会尝试修改项目设置。

通过工作树，您可以避免不断的重新configuration。签出使用工作树在单独的文件夹中的旧分支。对于每个分支，你有一个独立的IDE项目。

当然这可以通过几次克隆回购来完成，这是我迄今为止的做法。但是，这也意味着浪费硬盘空间，而且需要多次从回购仓库获取相同的更改。

现在，唯一缺less的部分是Windows的官方git 2.5版本，但有一个希望，即将推出新的Windows混帐 🙂

我可以看到一些用途。

如果你有一个运行了很长时间的testing套件，想象几个小时，然后开始它，它将有效地阻止这个工作副本，直到testing完成。在这些testing中切换分支将会以难以理解的方式打破它们。

所以用git-worktree我可以为在那里工作的另一个分支启动第二个想法。

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

第三个用例是使用除了git-diff之外的其他工具进行文件比较，就像两个目录之间的普通diff ，而不是两个分支。

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

我在本地尝试了这一点。

创build一个目录page1 。
里面创build目录src和git init它。
在src创build一个小的内容page1.html并提交它。
$ git branch ver0
$ git worktree add ../V0 ver0
在src master中添加更多文本到page1.html并提交它。
$ git branch sty1
编辑page1.html分支中的page1.html （添加一些独特的CSS样式）并添加提交。
$ git worktree add ../S1 sty1

您现在可以使用Web浏览器同时打开并查看这3个版本：

..\page1\src\page1.html //任何git作为当前
..\page1\V0\page1.html //最初的版本
..\page1\S1\page1.html //实验样式的版本

为什么你一次需要在文件系统中需要/需要多个工作树呢？
- 操作检出的文件，同时需要在其他地方进行更改（例如，编译/testing）
- 通过普通的差异工具来区分文件
- 在合并冲突期间，我经常想要在源代码中导航源代码，同时解决文件中的冲突。
- 如果您需要大量来回切换，则会浪费时间检查并重新检查您不需要使用多个工作pipe理。
- 通过git存储在分支之间的心理上下文切换的精神成本是不可测量的。有些人发现，存在精神成本隐藏，不是简单地打开不同目录中的文件。
有人问“为什么不做多个本地克隆”。确实，使用“–local”标志，您不必担心额外的磁盘空间使用情况。这个（或者类似的想法）就是我现在所做的。链接到本地克隆工作的function优势是：
1. 使用本地克隆，您的额外工作树（位于本地克隆中）根本无法访问原始或上游分支。克隆中的“起源”将不会与第一个克隆中的“起源”相同。
  - 运行git log @{u}..或git diff origin/feature/other-feature可能会非常有帮助，而且这些都不可能再有困难了。这些想法在技术上可能通过各种工作区的本地克隆来实现，但是通过链接的工作区，您可以做的每个解决方法都会更好和/或更简单。
2. 您可以在工作区之间共享参考。如果你想比较或借用另一个本地分支的变化，现在你可以。

tl; dr：无论git-worktree ，无论出于何种原因，您希望同时检出两个工作树， git-worktree是一种快速而节省空间的方法。

如果你创build了另一个工作树，那么repo的大部分（即.git ）将被共享，这意味着如果你在一个工作树中创build一个分支或者获取数据，那么它也可以从你拥有的其他工作树访问。假设你想在分支foo上运行你的testing套件，而不必将它推到某个地方克隆它，而且你想避免在本地克隆你的repo的麻烦，使用git-worktree是创build一个新的checkout的好方法在一个单独的地方暂时或永久地陈述。就像一个克隆一样，当你完成这个任务时，你需要做的就是删除它，并且在一段时间之后，对它的引用将被垃圾回收。

在想知道这些奇特的工作原理可以用于什么之后，我最初偶然发现了这个问题。从那时起，我已经将它们整合到了我的工作stream程中，尽pipe我最初的怀疑已经发现它们非常有用。

我在一个相当大的代码基础上工作，这需要花费相当长的时间来编译。我通常在我的机器上安装了当前的开发分支以及我目前正在使用的function分支以及表示当前系统当前状态的主分支。

对我来说最大的好处之一是显然，我不必每次切换分支（即工作区）时重新编译整个事物。一个好的副作用是我可以去开发工作，做那里的东西，改变目录到我目前的function分支的工作树，然后重新绑定它，而不必先拉。

我有一个相当不寻常的：我在同一台机器上进行Windows和Linux的开发。我有一个运行在我的Windows中的Linux的VirtualBox框。 VirtualBox装载一些Windows目录，并直接在Linux机器中使用它们。这使我可以使用Windows来pipe理文件，但在Linux中构build。这是一个跨平台的项目，所以它从同一个目录结构的Windows和Linux上构build。

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

在一个理想的世界中，构build系统将被修改，以便Windows和Linux可以在目录内共存，但现在，问题正在通过工作区来解决。 “Linux”文件夹可以生成特定于Linux的构build工件，“Windows”文件夹可以生成特定于Windows的构build工件。虽然这不是一个理想的解决scheme，但是在等待构build系统bug被解决的时候，它是一个很好的权宜之计。

诚然，工作树不是为此而devise的; 我必须将Windows版本和Linux版本保留在不同的分支上，尽pipe我更喜欢它们在同一个分支上。尽pipe如此，它还是在做这项工作，而且这是一个不寻常的案例，可以节省一天的时间。

在我的新项目中，我创build了一个function。但有些规格失败了。为了与master比较结果，我创build了一个work-tree回购。我在运行代码中逐步比较结果，直到明白出了什么问题。