Git worktree 是什么，为什么值得使用？-未完纪

Git 最近最热门的话题似乎是 worktree，也就是工作树。这其实有点有趣，因为它从 2015 年就已经存在了。

不过，worktree 确实很棒。你可能想知道：为什么要使用它？它和分支有什么区别？又为什么突然流行起来？

下面就来聊聊。

使用分支与 stash 切换上下文

假设你生活在没有 worktree 的世界，正在处理一张任务单，突然遇到紧急缺陷，不得不切换工作。

首先，你可能会暂存手头的修改：

git stash "wip feature login"

然后切换到主分支并更新：

git checkout main 
git pull origin main

再创建修复缺陷的分支：

git checkout -b hotfix-bug

接着修复问题，提交，并推送分支：

git add . 
git commit -m "fix broken submit button" 
git push origin hotfix-bug

合并拉取请求后，回到电脑上拉取主分支，并删除修复分支：

git checkout main 
git pull origin main 
git branch -d hotfix-bug

最后才能回到先前开发的功能：

git checkout feature-login 
git stash pop

呼，刚才做到哪儿了？

来回切换、重新加载文件、根据变化重新安装 node_modules 等操作，带来了不少心智负担。上下文切换的成本很高。

这只是个简单例子。有时开发者会用更复杂的 git stash 命令处理这类混乱，甚至将同一个仓库克隆多份。原作者也这样做过。

直到遇见 worktree。

有了 worktree，你不必离开当前分支，也不必 stash；原功能在编辑器中的工作状态会完整保留。

git worktree add ../hotfix-workspace -b hotfix-bug main

该命令会立即创建名为 hotfix-workspace 的同级目录，以 main 为基础，并检出名为 hotfix-bug 的新分支。

现在，可以在新的编辑器窗口中打开该目录，或者 cd 进入目录，着手修复缺陷。原来的编辑器窗口则保持原样。

cd ../hotfix-workspace 
# ...fix fix fix... 
git add . 
git commit -m "fix broken submit button" 
git push origin hotfix-bug

和之前一样，在网站上合并拉取请求。合并后，只需要移除临时目录：

cd ../main-project 
git worktree remove ../hotfix-workspace

这样顺畅多了！worktree 的使用也不限于 Git 命令行。例如，VS Code 内置了完整的 worktree 支持，你可以选择适合自己的方式。无论在哪里工作，worktree 都可以避免 stash 冲突，不打断编辑器状态，并真正支持并行工作。

很长一段时间里，worktree 相对冷门。多数开发者从未听说过它，要么因为 Git 图形界面没有支持它，或者支持不够完善；要么因为大家习惯遵循熟悉的流程：创建功能分支、开发、提交拉取请求、合并，然后重复。

现在，开发者的工作方式变了。AI 让我们进行的并行工作，比软件开发历史上任何时期都多。开发者同时运行许多会话，“代码审查文化”也在超越“代码编写文化”。

借助 worktree，代理和人类都能并行完成更多工作。它是 GitHub Copilot 应用的默认模式，也是许多现代工具采用的方式。

worktree 能解决许多问题，但仍有一些事项值得注意。

依赖膨胀：每个 worktree 目录都需要自己的一份项目依赖。如果在多个工作树中运行 npm install 或 pip install，磁盘可能很快被占满。
目录管理：需要删除不再使用的 worktree 目录，避免父目录越来越杂乱。GitHub Copilot 应用这类工具通常会代为处理，但如果直接使用终端，这仍可能需要自己完成。
忽略规则：如果在主仓库目录内部创建 worktree 目录，必须手动把它们加入 .gitignore，以免意外跟踪。也可以将工作树放在主仓库外，许多应用默认就是这样做的，但仍值得注意。
同一分支的限制：Git 不允许在两个不同的 worktree 中同时检出完全相同的分支，以防止数据损坏。