我会用 git-worktree 做什么？

What would I use git-worktree for?

提问by awendt

I read Github's post on git-worktree. They write:

我在 git-worktree 上阅读了Github 的帖子。他们写：

Suppose you're working in a Git repository on a branch called feature, when a user reports a high-urgency bug in master. First you create a linked working tree with a new branch, hotfix, checked out relative to master […] You can fix the bug, push hotfix, and create a pull request.

假设您在名为 的分支上的 Git 存储库中工作feature，当用户报告master. 首先，您创建一个带有新分支的链接工作树，hotfix相对于 master 签出 [...] 您可以修复错误、推送修补程序并创建拉取请求。

When I'm working on a branch called feature and some high-urgency bug in master is reported, I usually stash away whatever I'm working on and create a new branch. When I'm done, I can continue working. This is a very simple model, I've been working like that for years.

当我在一个名为 feature 的分支上工作并且报告了 master 中的一些高紧急错误时，我通常会隐藏我正在处理的任何内容并创建一个新分支。完成后，我可以继续工作。这是一个非常简单的模型，我多年来一直这样工作。

On the other hand, using git-worktree has its own limitations:

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

For example, it's not allowed to have the same branch checked out in two linked working trees at the same time, because that would allow changes committed in one working tree to bring the other one out of sync.

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

Why would I choose a more complicated workflow for a problem that's already been solved?

为什么我要为已经解决的问题选择更复杂的工作流程？

Is there anything about git-worktreethat couldn't be done beforehand and that justifies this whole new, complex feature?

有什么事情git-worktree不能事先完成，并且证明这个全新的、复杂的功能是合理的？

采纳答案by Sebi

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.

对我来说，git worktree 是很长一段时间以来最大的改进。我从事企业软件开发。在那里，您必须像 3 年前发布的版本一样维护旧版本是很常见的。当然，每个版本都有一个分支，以便您可以轻松切换到它并修复错误。然而，切换是昂贵的，因为在此期间您完全重构了存储库，并且可能构建系统。如果您切换，您的 IDE 将疯狂地尝试调整项目设置。

With worktree, you can avoid that constant reconfiguration. Checkout those old branches in separate folders using worktree. For each branch, you got an independent IDE project.

使用工作树，您可以避免不断的重新配置。使用工作树检查单独文件夹中的旧分支。对于每个分支，您都有一个独立的 IDE 项目。

Of course this could have been done in the past by cloning the repo several times and this has been my approach so far. However, that also meant wasting hardrive space and worse needing to fetching the same changes from the repo several times.

当然，这在过去可以通过多次克隆 repo 来完成，到目前为止这是我的方法。然而，这也意味着浪费硬盘空间，更糟糕的是需要多次从 repo 中获取相同的更改。

回答by Andreas Wederbrand

I can see some uses for this.

我可以看到一些用途。

If you have a test suite that runs for a long time, imagine hours, and you start it it effectively blocks that working copy until the tests are completed. Switching branches during those tests would break them in ways that would be hard to understand.

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

So with git-worktreeI could have a second idea launched for another branch doing work there.

因此，git-worktree我可以为另一个在那里工作的分支机构启动第二个想法。

Also, when I switch to some other branch to do some quick investigation my IDE thinks a lot of files suddenly changed and will index all those changes, just to have to re-index them again when I'm switching back.

此外，当我切换到某个其他分支进行一些快速调查时，我的 IDE 认为很多文件突然更改并将索引所有这些更改，只是在我切换回来时必须再次重新索引它们。

A third use case would be to do file comparison using other tools than git-diff, like normal diff, between two directories instead if two branches.

第三个用例是在两个目录之间而不是两个分支之间使用其他工具进行文件比较git-diff，例如 normal diff。

回答by RodMcGuire

One obvious use is to simultaneously compare the behavior(not source) of different versions - for example different versions of a web site or just a web page.

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

I tried this out locally.

我在本地试过了。

• create a directory page1.

• inside create the directory srcand git initit.

• in srccreate page1.htmlwith a little content and commit it.

• $ git branch ver0

• $ git worktree add ../V0 ver0

• in srcmaster add more text to page1.htmland commit it.

• $ git branch sty1

• edit page1.htmlin the sty1branch (add some distinctive CSS style) and add commit it.

• $ git worktree add ../S1 sty1

• 创建一个目录page1。

• 在里面创建目录src和git init它。

• 在src创建page1.html一个小的内容和提交。

• $ git branch ver0

• $ git worktree add ../V0 ver0

• 在srcmaster 中添加更多文本page1.html并提交。

• $ git branch sty1

• page1.html在sty1分支中编辑（添加一些独特的 CSS 样式）并添加提交。

• $ git worktree add ../S1 sty1

You can now use a web browser to open and view these 3 versions simultaneously:

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

• ..\page1\src\page1.html// whatever git has as current

• ..\page1\V0\page1.html// the initial version

• ..\page1\S1\page1.html// the experimentally styled version

• ..\page1\src\page1.html// 无论 git 有什么作为当前

• ..\page1\V0\page1.html// 初始版本

• ..\page1\S1\page1.html// 实验风格的版本

回答by Alexander Bird

1. There are legitimate reasons why you may want/need multiple worktrees in the filesystem at once.

   • manipulating the checked out files whileneeding 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 whileresolving 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.

2. 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:

   1. 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-featurecan 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.

   2. You can share refs between worktrees. If you want to compare or borrow changes from another local branch, now you can.

1. 您可能需要/需要一次在文件系统中使用多个工作树是有正当理由的。

   • 操作签出的文件，同时需要在其他地方进行更改（例如编译/测试）

   • 通过普通的差异工具比较文件

   • 在合并冲突，我常常想通过源代码进行导航，因为它是在源端，而解决这些文件冲突。

   • 如果您需要来回切换很多次，就会浪费时间检出和重新检出您不需要处理多个工作树。

   • 通过 git stashing 在分支之间切换心理上下文的心理成本并不是真正可以衡量的。有些人发现通过简单地打开不同目录中的文件来存储不存在的精神成本。

2. 有人问“为什么不做多个本地克隆”。确实，使用“--local”标志您不必担心额外的磁盘空间使用。这（或类似的想法）是我到目前为止所做的。链接工作树相对于本地克隆的功能优势是：

   1. 使用本地克隆，您的额外工作树（位于本地克隆中）根本无法访问源或上游分支。克隆中的“起源”将与第一个克隆中的“起源”不同。

      • 跑步git log @{u}..或git diff origin/feature/other-feature可以非常有帮助，而这些要么不再可能，要么更加困难。这些想法在技术上可以通过各种变通方法在本地克隆中实现，但是您可以通过链接的工作树来更好和/或更简单地完成每个变通方法。

   2. 您可以在工作树之间共享参考。如果您想比较或借用其他本地分支的更改，现在您可以。

回答by jsageryd

tl;dr: Any time you want to have two work trees checked out at the same time for whatever reason, git-worktreeis a quick and space-efficient way to do it.

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-worktreeis 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）将被共享，这意味着如果您在一个工作树中创建一个分支或获取数据，它也可以从您拥有的任何其他工作树访问。假设你想在分支 foo 上运行你的测试套件而不必将它推送到某个地方来克隆它，并且你想避免在本地克隆你的 repo 的麻烦，使用git-worktree是一个很好的方法来创建一个新的某个状态的检出临时或永久分开的地方。就像克隆一样，当你完成它时你需要做的就是删除它，一段时间后对它的引用将被垃圾收集。

回答by rethab

I originally stumbled on this question after wondering what these fancy worktrees could be used for. Since then I have integrated them into my workflow and in spite of my initial scepticism I have come to find them quite useful.

在想知道这些花哨的工作树可以用来做什么之后，我最初偶然发现了这个问题。从那时起，我将它们集成到我的工作流程中，尽管我最初持怀疑态度，但我发现它们非常有用。

I work on a rather large code-base, which takes quite some time to compile. I usually have the current development branch on my machine along with the feature branch I am currently working on plus the master branch, which represents the current state of the live system.

我在一个相当大的代码库上工作，这需要相当长的时间来编译。我通常在我的机器上有当前的开发分支以及我当前正在处理的功能分支以及代表实时系统当前状态的主分支。

One of the biggest benefits for me is obviously that I don't have to recompile the entire thing everytime I switch branches (that is, worktrees). A nice side-effect is that I can go to the development worktree, do stuff there, change directory to the worktree for my current feature branch and then rebase it without having to pull first.

对我来说最大的好处之一显然是我不必每次切换分支（即工作树）时都重新编译整个东西。一个很好的副作用是，我可以转到开发工作树，在那里做一些事情，将目录更改为我当前功能分支的工作树，然后无需先拉取即可重新设置它的基础。

回答by AHelps

I've got a rather unusual one: I am doing Windows and Linux development on the same machine. I have a VirtualBox running Linux inside of my Windows box. The VirtualBox mounts some Windows directories and uses them directly inside of the Linux machine. This lets me use Windows to manage files but build within Linux. This is a cross-platform project, so it builds on both Windows and Linux from the same directory structure.

我有一个相当不寻常的：我在同一台机器上进行 Windows 和 Linux 开发。我的 Windows 盒子中有一个运行 Linux 的 VirtualBox。VirtualBox 挂载一些 Windows 目录并直接在 Linux 机器内部使用它们。这让我可以使用 Windows 来管理文件，但在 Linux 中构建。这是一个跨平台项目，因此它从相同的目录结构构建在 Windows 和 Linux 上。

The problem is that the Linux and Windows build systems crash into each other when used in the same directory; there are some complicated build steps for downloading libraries, etc., that use the same directory names. The Windows version of the build system downloads the Windows-specific libraries, and the Linux version of the build system downloads the Linux-specific libraries.

问题是Linux 和Windows 构建系统在同一目录下使用时会相互崩溃；下载使用相同目录名的库等需要一些复杂的构建步骤。构建系统的 Windows 版本下载 Windows 特定的库，构建系统的 Linux 版本下载 Linux 特定的库。

In an ideal world, the build system would be modified so that Windows & Linux can co-exist within the directory, but for now, the problem is being addressed with worktrees. The "Linux" folder can generate Linux-specific build artifacts, and the "Windows" folder can generate Windows-specific build artifacts. While this is hardly an ideal solution, it makes a nice stopgap while waiting for the build system bugs to be addressed.

在理想的世界中，构建系统将被修改，以便 Windows 和 Linux 可以在目录中共存，但目前，问题正在通过工作树解决。“Linux”文件夹可以生成特定于 Linux 的构建工件，而“Windows”文件夹可以生成特定于 Windows 的构建工件。虽然这不是一个理想的解决方案，但在等待构建系统错误得到解决时，它是一个很好的权宜之计。

Admittedly, worktree wasn't designed for this; I have to keep the Windows version and the Linux version on separate branches, even though I'd really prefer them to be on the same branch. Still, it's doing the job, and is a somewhat unconventional case of worktree saving the day.

不可否认，worktree 并不是为此而设计的。我必须将 Windows 版本和 Linux 版本保留在不同的分支上，即使我真的希望它们位于同一个分支上。尽管如此，它仍然在做这项工作，并且是一个有点非常规的工作树拯救世界的案例。

回答by itsnikolay

In new project for me, I've created a feature. But some specs failed. To compare results with masterI created a work-treerepo. I compared results step by step in run code, until understand what went wrong.

在我的新项目中，我创建了一个功能。但是一些规格失败了。为了与结果进行比较，master我创建了一个work-treerepo。我在运行代码中一步一步地比较了结果，直到明白出了什么问题。

回答by Ricardo M S

I'm using git worktreefor machine learning development.

我正在git worktree用于机器学习开发。

I have a main functional code and then I want to split branches of different experiments (different algorithms and different hyperparameters). git worktreeallows me to integrate dvcalongside different versions of my code specialized to different algorithms. After running all training jobs I evaluate final metrics and merge to master the best branch/model.

我有一个主要的功能代码，然后我想拆分不同实验的分支（不同的算法和不同的超参数）。git worktree允许我将dvc与专用于不同算法的不同版本的代码集成在一起。运行所有训练作业后，我评估最终指标并合并以掌握最佳分支/模型。