一个git工作树支持多个分支吗？

Question

根据文档，每个分支git worktree提供一个branch（dev/ feature/prod等），但对我来说这听起来也不合理，每个分支都有自己的文件夹，因为worktree它会创建许多文件夹，并且在某些时候可能会令人困惑。

一个git worktree可以支持多个吗branches？例如，所有属于哪个分支feature，然后在什么相关的时刻之间切换？这是正确的做法吗？

Answer 1

git worktree创建一个新的签出，共享您现有的本地存储库。它有自己的 HEAD，用于跟踪当前签出的提交，以及自己的用于构建提交的暂存区域。它的主要目的是能够同时在多个分支上工作，而无需克隆整个存储库或隐藏您的更改。

工作树的工作原理本质上与任何其他结帐类似。您可以切换到您喜欢的任何分支，除非它已经被另一个工作树检出。您可以运行 git-bisect。你可以重新设定基准。

工作树不必用于新分支，它可以用于现有分支。git worktree add ../temp master将创建一个工作树，其中 master 已签出。

如果您打算同时在多个分支上工作，则只需创建工作树。例如，您正在开发一项功能，并且有许多未提交的更改，并且出现了紧急修复。您可以为该修复创建一个工作树，在工作树中进行修复，然后返回到原始功能工作。或者也许您想针对旧版本测试某些内容，您可以制作一个工作树并签出旧版本。

良好的开发流程并不要求您同时在多个分支上工作。

Answer 2

施文写道：

您可以切换到您喜欢的任何分支，除非它已经被另一个工作树检出。您可以运行 git-bisect。你可以重新设定基准。

但是...如果您在当前的工作树中处于二等分或变基的中间，则不应切换分支。

在 Git 2.38 之前，这一点并没有强制执行。

在 Git 2.38（2022 年第 3 季度）中，引入一个帮助程序来查看分支是否已经在处理（因此不应在工作树中重新检出），它的性能比现有的要好得多，可以替代后者的许多用途find_shared_symref()。

请参阅提交 4b6e18f、提交 b489b9d、提交 12d47e3、提交 d2ba271、提交 31ad6b6（2022 年 6 月 14 日），作者：Derrick Stolee ( derrickstolee)。
请参阅Jeff King的提交 9bef0b1和提交 b2463fc（2022 年 6 月 18 日）。^{（由Junio C Hamano 合并 -- --在提交 c2d0109中，2022 年 7 月 11 日）}peff
gitster

branch：检查平分和变基

^{签署人：Derrick Stolee}

该branch_checked_out()帮助器是由之前的更改添加的，但它使用了过于简化的视图来检查分支是否已签出。
它只关注 HEAD symref，但忽略是否发生了平分或变基。

教branch_checked_out()检查这些事情，并添加测试以确保我们将来不会失去此功能。

现在这个测试覆盖率已经存在，我们可以安全地重构validate_new_branchname()以使用branch_checked_out().

请注意，我们需要在调用后将“refs/heads/”添加到“state.branch”中wt_status_check_*()。
我们还需要复制，wt->path以便在调用结束时不会释放该值。

更改正在重新设定基数（或一分为二）的工作树中的分支将导致：

 cannot force update the branch <abranch> checked out at <worktree path>

在 Git 2.42（2023 年第 3 季度）中，“ git branch -f X” ^（man）重新指向分支X表示X已在另一个工作树中签出，即使分支X没有被平分或重新基址。
该消息被改写为该分支机构“正在使用中”。

请参阅Junio C Hamano ( )的提交 4970bed（2023 年 7 月 21 日）。^{（由Junio C Hamano 合并 -- --在提交 65e25ae，2023 年 8 月 4 日）}gitster
gitster

branch：更新消息以拒绝触摸正在使用的分支

^{帮助者：乔什·斯雷夫}

“ git branch -f” ^{( man )}命令可以拒绝强制更新另一个工作树使用的分支。
这种行为的最初理由是，更新在另一个工作树中检出的分支，而不对该工作树中的索引和工作树文件进行匹配的更改，将导致用户非常困惑。
“ git diff” ^{( man )} HEAD 将不再提供有用的补丁，因为 HEAD 是与工作树中的索引和工作树所基于的内容无关的提交。

如今，相同的机制还可以保护正在重新定位或分割的分支，并且当我们决定保护正在进行其他类型操作的分支时，相同的机制预计将是添加更多检查的正确位置。
然而，我们忘记重新考虑消息传递，消息最初表示我们拒绝触及分支，因为它在其他地方“签出”，当d2ba271 (“ branch：检查二等分和变基”，2022-06-14，Git v2.38.0 -rc0 --批次 #1中列出的合并开始保护正在重新设置基址或一分为二的分支。

检查的精神始终是我们不想破坏其他工作树中同一分支的使用。
让我们稍微改写该消息，说该分支被另一个工作树“使用”，而不是“签出”。

我们可以教该branch.c:prepare_checked_out_branches()函数记住为什么它决定某个特定分支需要保护（即是
因为它被签出？被一分为二？其他什么？）以及该分支正在使用哪个工作树，并在错误中使用它消息说“ you cannot force update this branch because it is being bisected in the worktree X”等，但这种额外的复杂性是否值得值得怀疑。
该消息已经告诉了所讨论的工作树位于哪个目录，并且chdir如果用户感到足够好奇，那么用户应该只需一个“”即可找出它处于什么状态。
所以我们暂时不要去那里。

不再：

checked out at ...

但反而：

used by worktree at ...

在 Git 2.44（2024 年第一季度）中，“ git checkout -B <branch> [<start-point>]” ^（man）允许更新和签出另一个工作树中正在使用的分支，这可能有点出乎意料。
规则已经收紧，这是一个突破性的变化。如果您习惯了
“ ”优先于安全性的当前行为，则需要“”选项来解除您的破坏。--ignore-other-worktrees-B

请参阅Junio C Hamano ( )的提交 b23285a和提交 9263c40（2023 年 11 月 23 日）。^{（由Junio C Hamano 合并 -- --于2023 年 12 月 27 日提交 f09e741）}gitster
gitster

checkout：禁止“-B”接触其他地方使用的分支

^{报道者：威廉·弗斯特拉滕}

“ git checkout -B <branch> [<start-point>]” ^{( man )}<branch>是“-b”的“强制”版本，在选择性地将其尖端重置为 后切换到<start-point>，即使<branch>正在另一个工作树中使用，这有点出乎意料。

使用禁止“ ”<branch>的相同逻辑来保护^{( man )}git checkout <branch>接触其他地方正在使用的分支的

这是一个重大更改，可能需要在发行说明中发出向后兼容性警告。
如果现有用户的手指记忆取决于“ ”的当前行为，则“ --ignore-other-worktrees”选项可以用作逃生口-B。

git checkout现在包含在其手册页中：

成功（例如，当分支在另一个工作树中使用时，不仅当前分支保持不变，而且分支也不会重置到起点）。

git switch现在包含在其手册页中：

也就是说，除非“ git switch”成功，否则不会重置/创建分支（例如，当分支在另一个工作树中使用时，不仅当前分支保持不变，而且分支不会重置到起点， 任何一个）。