《Git worktree 为什么重新变成开发者高频工具》

导语

这篇 GitHub Blog 文章解释了一个看似老工具为什么突然变得重要：git worktree 从 2015 年就存在，但在 AI 编程、并行 session 和代码评审文化兴起后，它重新变成开发者处理多任务的实用基础设施。作者不是单纯介绍命令，而是用“紧急修 bug 时怎样切换上下文”来说明 worktree 解决了什么痛点、有什么成本，以及它为什么适合 Copilot app 这类现代工具。

1. 没有 worktree 时，分支和 stash 会放大上下文切换成本

作者先假设一个常见场景：你正在开发 feature-login，突然收到一个 urgent bug，需要立刻切到 main 上修复。传统做法并非不能完成任务，但它把注意力切成一串机械动作。

1.1 传统流程需要不断保存、切换、更新、再恢复

• 你可能先用 git stash 并写下 “wip feature login” 暂存当前工作，再切到 main、拉取远端更新，然后新建 hotfix-bug 分支修复问题、提交、推送、合并 PR。
• 修完之后，你还要回到本地，拉取最新 main、删除 hotfix 分支，再切回 feature-login 并把 stash 弹回工作区。问题不在于这些命令难，而在于每一步都在迫使开发者中断原来的心智现场。

1.2 真正的损耗来自编辑器、依赖和思路被一起打断

• 作者把这种疲惫称为 mental overhead：切分支会导致文件重新加载，依赖如 node_modules 可能跟着变化，编辑器状态和原本的任务上下文也会被冲散。
• 一些开发者会用更复杂的 stash 技巧，或者干脆克隆多个仓库来绕开混乱。作者承认自己也这么做过，这为 worktree 的价值做了铺垫：它不是替代分支，而是减少并行工作时的干扰。

2. worktree 把“修 bug”放进另一个工作目录，而不是打断当前分支

作者接着给出 worktree 版本的同一场景。核心差异是：你不需要离开当前分支，也不需要 stash；原来的编辑器窗口可以保持原样。

2.1 一个命令创建独立的 hotfix 工作区

• git worktree add 这一命令会创建一个相邻文件夹 hotfix-workspace，基于 main 检出新分支 hotfix-bug。这等于给同一个仓库开了另一个工作目录。
• 接下来你可以进入 ../hotfix-workspace，在新窗口里修复、暂存改动、提交并推送，然后像平常一样在线合并 PR。原来的 feature 工作区没有被移动、覆盖或暂存，开发者可以真正并行处理两件事。

2.2 修完后删除临时工作区即可回到原现场

• PR 合并后，你回到主项目目录，执行 git worktree remove ../hotfix-workspace 删除这个临时工作区。这里没有 stash 冲突，也没有编辑器被迫切换的扰动。
• 这就是作者说 worktree “smoother”的原因：它把上下文切换从“在同一个目录反复折叠状态”，改成“在多个目录并列展开状态”。

3. worktree 为什么现在突然流行

很长时间里，worktree 相对冷门。作者给出两个原因：Git GUI 支持不足，或者把它当成二等功能；多数团队也习惯了“feature branch -> work -> PR -> merge -> repeat”的线性工作方式。

但开发方式变了。AI 让开发者和代理可以同时跑更多 session，“code review culture” 也正在变得比单纯“code writing culture”更突出。当人和 agents 都需要并行尝试、修复、评审时，worktree 就从冷门 Git 功能变成了多线程开发的默认工作台。

GitHub Copilot app 和许多现代工具把 worktree 作为默认模式，正是因为它天然适合“多个任务同时存在，但互不踩踏”的工作方式。

4. worktree 的四个注意事项

作者没有把 worktree 描述成无成本方案，而是列出几个使用时需要留意的限制。

4.1 依赖会膨胀

• 每个 worktree 文件夹都可能需要自己的项目依赖。如果多个 worktree 都安装 Node 或 Python 依赖，磁盘空间会很快变满。

4.2 文件夹需要管理

• 临时 worktree 用完后要删除，否则父目录会慢慢堆满旧工作区。GitHub Copilot app 这类工具可能会帮你处理，但终端用户仍要自己记得清理。

4.3 位置放错时需要处理 .gitignore

• 如果你把 worktree 文件夹创建在主仓库目录内部，就需要把它们加入 .gitignore，否则可能意外被追踪。作者也提醒，可以把 worktree 放在主仓库外部，许多 app 默认也是这样做的。

4.4 同一个分支不能在两个 worktree 同时检出

• Git 会阻止你在两个不同 worktree 中同时检出同一个分支，这是为了避免数据损坏。这个限制说明 worktree 虽然并行，但仍然遵守 Git 对分支状态一致性的保护。

5. 在 GitHub Copilot app 里，worktree 被做成默认体验

在 Copilot app 中，worktree 几乎不需要用户显式理解命令。首页会有一个 dropdown 让你选择新 session 的运行位置，默认就是新 worktree。

启动 session 后，点击顶部 session 名称，就能看到自动生成的 worktree 名字、它所在的路径、所属项目，以及本次 session 做出的改动。这里还有一个原文小错：作者写成了 bath，语境上应是 path。这个细节不影响主线，主线是 Copilot 把 worktree 封装成“默认并行工作空间”。

6. 是否该使用 worktree：取决于你的并行工作密度

作者最后给出一个 senior developer 式答案：It depends。你可能仍喜欢单目录、分支和 stash 的心智模型；也可能以后几乎都用 worktree；还可能两者混用。

文章的落点不是让所有开发者立即迁移，而是说明当开发工作越来越并行，worktree 提供了一种低摩擦地保留上下文、隔离任务和协作 agents 的方式。它适合那些经常同时修 bug、跑实验、处理评审或使用 AI 编程 session 的团队。

思想框架

文章先用一个紧急 hotfix 场景重建传统 branch + stash 流程，让读者感受到上下文切换的真实摩擦；再用 git worktree add 展示同一任务如何被放进相邻目录，从而保留原分支和编辑器状态。随后，作者把 worktree 的重新流行放进 AI 编程和并行 code review 的变化中解释：当人和 agents 同时处理多个任务时，线性分支切换不再够用。最后，文章列出依赖膨胀、文件夹清理、.gitignore 和同分支限制四个注意点，并把 GitHub Copilot app 的默认 worktree 体验作为现代工具已经采纳这一模式的例子。