什么是 git worktrees，为什么要使用它们？

最近，git 里最火的概念似乎是 worktree。不过……这多少有点好笑，因为它早在 2015 年就已经存在了。

但不管怎样，worktree 确实很酷。你可能会好奇为什么要用它，它和分支有什么不同，以及为什么它突然变得这么流行。

假设你生活在一个没有 worktree 的世界里，正在处理一个工单，突然来了一个紧急 bug，你不得不切换上下文。

首先，你可能会先 stash 当前工作：

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

接着修好问题、提交，并 push 这个分支：

然后，在合并一个 pull request 之后，你可能会回到自己的电脑上，拉取 main，并删除那个 bug 分支：

接着你就可以回到之前正在开发的功能上：

在不同分支之间来回切换、重新加载文件、根据变更重新安装 node_modules，诸如此类的心智负担很大。上下文切换的成本非常高。

当然，这只是一个基础示例，但有时开发者会用一些更复杂的 git stash 命令来绕开这种混乱，甚至会克隆同一个 repo 的多个副本（这事我也干过）。

有了 worktrees，你不需要离开当前分支，也不需要 stash，原本功能开发的编辑器上下文也会保持不变。

这会立即创建一个名为 hotfix-workspace 的同级文件夹，以 main 为基础，并检出一个名为 hotfix-bug 的新分支。

现在，你可以在新的编辑器窗口中打开那个文件夹（或者 cd 进去），然后修复这个 bug。原来的编辑器窗口会保持在你离开时的状态，完全不受影响。

你像之前一样在线合并 pull request；合并完成后，直接删除这个临时文件夹即可。

这样顺畅多了！Worktree 的用途也不止于 git 命令行。比如，VS Code 已经内置了完整的 worktree 支持。你有很多选择！而且无论在哪里工作，worktree 都能让你完全避免 stash 冲突的风险，不会打断编辑器状态，也能真正做到并行工作。

在很长一段时间里，worktree 都相对冷门。大多数开发者从未听说过它们，要么是因为 Git GUI 不支持 worktree（或者把它们当成二等功能），要么是因为大家通常只是沿用熟悉的流程：创建 feature branch、开发、提交 PR、合并，然后循环往复。

现在，开发者的工作方式已经变了。AI 让我们比软件开发史上任何时候都更需要并行工作。开发者会并行运行大量 session，而“代码审查文化”正在超越“代码编写文化”。

有了 worktree，agent 和人类都能更好地并行工作。这已经是 GitHub Copilot app 的默认模式，也是许多其他现代工具的默认模式。

Worktree 确实能解决很多问题，但也有一些地方需要注意。

依赖膨胀：每个 worktree 文件夹都需要一份项目依赖的独立副本。如果你在多个 worktree 里运行 npm install 或 pip install，电脑的存储空间可能很快就被占满。

文件夹管理：你需要删除 worktree 文件夹，避免父目录随着时间推移变得杂乱。GitHub Copilot app 这类应用通常会帮你处理这件事，但如果你是在终端里自己操作，可能仍然需要手动完成。

全局 .gitignore 要求：如果你在主仓库目录里创建 worktree 文件夹，就必须手动把它们加入 .gitignore，以免不小心被 Git 跟踪。你也可以把这些 worktree 放在主仓库之外（很多应用默认就是这么做的），但这一点仍然值得注意。

单分支限制：为了防止数据损坏，Git 不允许你在两个不同的 worktree 中同时检出完全相同的分支。

问得好！很棒的一点是，它们开箱即用。打开应用后，首页会有一个下拉菜单，询问你想在哪里运行新的 session。默认选项就是新的 worktree。

然后，一旦你启动了一个新的 session，就可以点击应用顶部的 session 名称，你会看到这个 worktree 自动生成的（很有趣的）名称，以及它所在的路径、这个 worktree 对应的项目，还有你已做更改的详细信息。

我会给出一个尽可能资深开发者式的回答：看情况！你可能更喜欢某一种工作方式。你可能不会做太多并行工作，也喜欢分支和 stash 这种心智模型。你也可能从现在开始只用 worktree。你还可能两种都想用！

选择权在你手里，现在就可以在 GitHub Copilot 应用中把这些方式都试一遍。

Cassidy 是 GitHub 的开发者倡导高级总监。她喜欢构建软件、为初创公司提供建议，也喜欢教开发者如何构建得更好。她每周都会在 cassidoo.co/newsletter 发布 newsletter，你可以在收件箱里看到她的最新动态、练习编程题，以及收获一个笑话！

了解我作为高级管理者的一天，在使用 40 项自动化辅助后变成了什么样，并进一步了解其中一些我最喜欢的自动化。

Qubot 是我们内部由 Copilot 驱动的分析 agent，它让任何 GitHub 员工都可以用自然语言询问关于我们数据的问题。下面是我们在构建它的过程中学到的经验。

GitHub Copilot 如何让每个 session 中更多时间用于有价值的工作，从而让你的 credits 更经用。

订阅我们面向开发者的双周 newsletter，获取技巧、技术指南和最佳实践。