我将使用git-worktree做什么？

Question

我在Git-worktree上阅读了Github的帖子.他们写:

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

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

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

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

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

是否有任何关于git-worktree事先无法完成的事情,这证明了这一全新的复杂功能？

Answer 1

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

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

当然,这可以通过多次克隆回购来完成,这是迄今为止的方法.然而,这也意味着浪费硬盘空间,更糟糕的是需要多次从回购中获取相同的更改.

现在,唯一缺少的部分是Windows的官方git 2.5版本,但有希望很快就会发布新的git for windows :-)

Answer 2

我可以看到一些用途.

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

因此,git-worktree我可以为另一个分支机构在那里开展工作提出第二个想法.

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

第三个用例是使用其他工具进行文件比较,而不是git-diff像正常情况一样diff,在两个目录之间进行文件比较,而不是两个分支.

Answer 3

一个显而易见的用途是同时比较不同版本的行为(不是源) - 例如网站的不同版本或仅仅是网页.

我在当地尝试了这个.

• 创建一个目录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

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

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

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

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

Answer 4

1. 有理由说明您可能希望/需要在文件系统中同时使用多个工作树.

   • 在需要在其他地方进行更改时操纵签出的文件(例如,编译/测试)

   • 通过普通的diff工具区分文件

   • 在合并冲突期间,我经常想要在源代码中浏览源代码,同时解决文件中的冲突.

   • 如果你需要来回切换很多,那么就会浪费时间结账并重新检查你不需要多个工作项.

   • 通过git stashing在分支之间切换心理上下文的心理成本并不是真正可测量的.有些人发现通过简单地打开来自不同目录的文件,存在不存在的心理成本.

2. 有些人问"为什么不做多个本地克隆".确实,使用"--local"标志,您不必担心额外的磁盘空间使用情况.这个(或类似的想法)是我到目前为止所做的.链接工作树对本地克隆的功能优势是:

   1. 对于本地克隆,您的额外工作树(位于本地克隆中)根本无法访问原点或上游分支.克隆中的"起源"与第一个克隆中的"起源"不同.

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

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

Answer 5

我最喜欢的，可能也是每个人都应该使用的最常见的用例git worktree是审查队友的拉取请求，同时仍然在主工作树中进行更改。

Answer 6

tl; dr:无论出于何种原因,任何时候你想要同时检查两棵工作树,这git-worktree是一种快速,节省空间的方法.

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

Answer 7

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

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

对我来说最大的好处之一显然是我每次切换分支时都不需要重新编译整个东西(即工作树).一个很好的副作用是我可以进入开发工作树,在那里做一些事情,将目录更改为我当前功能分支的工作树,然后在不必先拉动的情况下重新设置它.

Answer 8

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

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

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

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

Answer 9

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

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