我读了Github上git-worktree的帖子。他们写道:
假设您正在一个名为feature的分支的Git存储库中工作，这时用户在master中报告了一个高度紧急的错误。首先，您可以创建一个带有新分支、hotfix、相对于master[…]签出的链接工作树。您可以修复错误、推送hotfix并创建一个拉取请求。
当我在一个叫做feature的分支上工作时，master中报告了一些非常紧急的bug，我通常会把我正在做的东西藏起来，然后创建一个新的分支。当我完成时，我可以继续工作。这是一个非常简单的模型，我已经做了很多年了。
另一方面，使用git-worktree也有其局限性:
例如，不允许在两个链接的工作树中同时签出同一个分支，因为这将允许在一个工作树中提交的更改导致另一个工作树不同步。
为什么我要为一个已经解决的问题选择一个更复杂的工作流?
在git-worktree中，是否有什么东西是事先无法完成的，从而证明了这个全新的、复杂的功能是合理的?
当前回答
我最初是在想这些花哨的工作树可以用来做什么时偶然发现这个问题的。从那以后，我将它们整合到我的工作流程中，尽管我最初持怀疑态度，但我逐渐发现它们相当有用。
我在一个相当大的代码库上工作，这需要相当长的时间来编译。我通常在我的机器上有当前的开发分支，以及我当前正在工作的特性分支，再加上主分支，它代表了活动系统的当前状态。
对我来说，最大的好处之一显然是，每次切换分支(即工作树)时，我都不必重新编译整个东西。一个很好的副作用是，我可以去开发工作树，在那里做一些事情，为我当前的特性分支更改目录，然后重新建立它，而不需要先拉。
其他回答
For me, git worktree is the biggest improvement since a long time. I'm working in enterprise software development. There, it is very common that you have to maintain old versions like what you released 3 years ago. Of course you have a branch for each version so that you can easily switch to it and fix a bug. However, switching is expensive, because in the meantime you completely restructured the repository and maybe build system. If you switch, your IDE will run mad trying to adapt the project settings.
使用工作树，您可以避免不断的重新配置。使用worktree将这些旧的分支签出到单独的文件夹中。对于每个分支，都有一个独立的IDE项目。
当然，这在过去可以通过多次克隆回购来实现，这一直是我到目前为止的方法。然而，这也意味着浪费硬盘空间，更糟糕的是需要多次从回购中获取相同的更改。
tl;dr:任何时候，无论出于什么原因，你想同时签出两个工作树，git-worktree是一种快速且节省空间的方法。
If you create another worktree, most parts of the repo (i.e. .git) will be shared, meaning if you create a branch or fetch data while you are in one work tree, it will also be accessible from any other work trees you have. Say you want to run your test suite on branch foo without having to push it somewhere to clone it, and you want to avoid the hassle of cloning your repo locally, using git-worktree is a nice way to create just a new checkout of some state in a separate place, either temporarily or permanently. Just like with a clone, all you need to do when you are done with it is delete it, and the reference to it will be garbage collected after some time.
我正在使用git工作树进行机器学习开发。
我有一个主要的功能代码，然后我想拆分不同实验的分支(不同的算法和不同的超参数)。Git工作树允许我将DVC与针对不同算法的不同版本的代码集成在一起。在运行所有的培训工作后，我评估最终的指标，并合并以掌握最好的分支/模型。
我最初是在想这些花哨的工作树可以用来做什么时偶然发现这个问题的。从那以后，我将它们整合到我的工作流程中，尽管我最初持怀疑态度，但我逐渐发现它们相当有用。
我在一个相当大的代码库上工作，这需要相当长的时间来编译。我通常在我的机器上有当前的开发分支，以及我当前正在工作的特性分支，再加上主分支，它代表了活动系统的当前状态。
对我来说，最大的好处之一显然是，每次切换分支(即工作树)时，我都不必重新编译整个东西。一个很好的副作用是，我可以去开发工作树，在那里做一些事情，为我当前的特性分支更改目录，然后重新建立它，而不需要先拉。
在我的新项目中，我创建了一个功能。 但一些规格失败了。为了与master比较结果，我创建了一个工作树repo。我在运行代码中一步一步地比较结果，直到了解哪里出了问题。
