There are legitimate reasons why you may want/need multiple worktrees in the filesystem at once. manipulating the checked out files while needing to make changes somewhere else (eg. compiling/testing) diffing the files via normal diff tools during merge conflicts, I often want to navigate through the source code as it is on source side while resolving conflicts in the files. If you need to switch back and forth a lot, there is wasted time checkout out and rechecking out that you don't need to do with multiple worktrees. the mental cost of mental context switching between branches via git stashing is not really measurable. Some people find that there is mental cost to stashing that isn't there by simply opening files from a different directory. Some people ask "why not do multiple local clones". It is true that with the "--local" flag you don't have to worry about extra disc space usage. This (or similar ideas) is what I have done up to this point. Functional advantages to linked worktrees over local clones are: With local clones, your extra worktrees (which are in the local clones) simply do not have access to origin or upstream branches. The 'origin' in the clone will not be the same as the 'origin' in the first clone. Running git log @{u}.. or git diff origin/feature/other-feature can be very helpful and these are either not possible anymore or more difficult. These ideas are technically possible with local clones via an assortment of workarouns, but every workaround you could do are done better and/or simpler through linked worktrees. You can share refs between worktrees. If you want to compare or borrow changes from another local branch, now you can.

There are legitimate reasons why you may want/need multiple worktrees in the filesystem at once. manipulating the checked out files while needing to make changes somewhere else (eg. compiling/testing) diffing the files via normal diff tools during merge conflicts, I often want to navigate through the source code as it is on source side while resolving conflicts in the files. If you need to switch back and forth a lot, there is wasted time checkout out and rechecking out that you don't need to do with multiple worktrees. the mental cost of mental context switching between branches via git stashing is not really measurable. Some people find that there is mental cost to stashing that isn't there by simply opening files from a different directory. Some people ask "why not do multiple local clones". It is true that with the "--local" flag you don't have to worry about extra disc space usage. This (or similar ideas) is what I have done up to this point. Functional advantages to linked worktrees over local clones are: With local clones, your extra worktrees (which are in the local clones) simply do not have access to origin or upstream branches. The 'origin' in the clone will not be the same as the 'origin' in the first clone. Running git log @{u}.. or git diff origin/feature/other-feature can be very helpful and these are either not possible anymore or more difficult. These ideas are technically possible with local clones via an assortment of workarouns, but every workaround you could do are done better and/or simpler through linked worktrees. You can share refs between worktrees. If you want to compare or borrow changes from another local branch, now you can.

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

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

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

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.

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

我在当地试过。

创建目录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 //实验风格的版本