Git worktrees 自 2015 年就已存在，但最近又重新流行起来。@cassidoo 解释了它们是什么，以及为什么在 AI 时代，并行工作让它们变得不可或缺。https://github.blog/ai-and-ml/github-copilot/what-are-git-worktrees-and-why-should-i-use-them/?utm_source=x-git-worktrees&utm_medium=social&utm_campaign=github-copilot-app-ga-2026…

什么是 Git Worktrees，以及为什么要使用它们？

来源：https://github.blog/ai-and-ml/github-copilot/what-are-git-worktrees-and-why-should-i-use-them/?utm_source=x-git-worktrees&utm_medium=social&utm_campaign=github-copilot-app-ga-2026 最近 Git 圈最火的概念似乎就是 worktrees 了。这有点搞笑，因为它们在 2015 年就已经存在了。

但话说回来，它们确实很酷，你可能会好奇为什么要用它们，它们和分支有什么区别，以及为什么突然变得这么流行。

我们来聊聊吧！

使用分支和 stash 进行上下文切换

假设你生活在一个没有 worktrees 的世界里，正在处理一个任务，突然一个紧急 bug 找上门来，你不得不切换上下文。

首先，你可能需要 stash 当前的工作：

git stash "wip feature login"

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

git checkout main git pull origin main

接着创建一个 bug 修复分支：

git checkout -b hotfix-bug

然后修复所有问题，提交并推送分支：

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

在合并 Pull Request 之后，你可能会回到电脑前，拉取主分支并删除 bug 分支：

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

然后才能回到之前正在开发的功能上：

git checkout feature-login git stash pop

呼……我们刚才在干什么来着？

切换来切换去、重新加载文件、根据修改重新安装 node_modules 等等，这些心理负担实在太重了。上下文切换的开销巨大。

当然，这只是一个基本例子，但有些开发者会通过更复杂的 git stash 命令，甚至多次克隆同一个仓库（我就干过这种事）来应对这种混乱。

直到……worktrees 的出现！

使用 Worktrees 进行上下文切换

有了 worktrees，你永远不会离开你的分支，也无需 stash，原始功能的编辑器上下文保持原样。

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

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

现在你可以在一个新的编辑器窗口中打开这个文件夹（或者 cd 进去）修复 bug。你的原始编辑器窗口保持原样。

`` cd ../hotfix-workspace

…修复修复修复…

git add . git commit -m “fix broken submit button” git push origin hotfix-bug ``

像之前一样在线合并 Pull Request，合并完成后，只需删除临时文件夹即可。

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

这样流畅多了！Worktrees 还可以超越 Git 命令行。例如，VS Code 内置了完整的 worktree 支持（https://code.visualstudio.com/docs/sourcecontrol/branches-worktrees#_working-with-git-worktrees）。你可以有多种选择！而且无论你在哪里工作，worktrees 都让你绝无 stash 冲突的风险，不会中断编辑器工作，真正实现并行开发。

那么……为什么是现在？

在很长一段时间里，worktrees 相对不为人知。大多数开发者从未听说过它们，可能是因为 Git GUI 不支持（或将其视为二等公民），或者因为他们通常遵循已知的模式：功能分支 -> 工作 -> PR -> 合并 -> 重复。

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

Agent 和人类可以通过 worktrees 实现更多并行工作。这是 GitHub Copilot 应用程序（https://github.com/features/ai/github-app?utm_source=blog-git-worktree&utm_medium=blog&utm_campaign=github-copilot-app-ga-2026）以及许多其他现代工具的默认模式。

有什么陷阱吗？

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

• 依赖膨胀：每个 worktree 文件夹都需要自己的项目依赖副本。如果你在多个 worktree 中运行 npm install 或 pip install，你的电脑可能会很快变得非常满。
• 文件夹管理：你需要删除 worktree 文件夹，以避免随着时间的推移弄乱父目录。像 GitHub Copilot 应用这样的工具通常会帮你处理，但如果你自己在终端操作，可能还是得自己动手。
• 全局 .gitignore 要求：如果你在主仓库目录内创建 worktree 文件夹，必须手动将它们添加到 .gitignore 中，以免意外被跟踪。你可以将这些 worktrees 放在主仓库之外（许多应用默认就是这样做的），但值得一提。
• 单一分支限制：Git 禁止你在两个不同的 worktrees 中同时检出完全相同的分支，以防止数据损坏。

如何在 GitHub Copilot 应用中使用 Worktrees？

好问题！很酷的是，它们开箱即用。当你打开应用时，首页会有一个下拉菜单，询问你在哪里运行新的会话。默认选项是新的 worktree。

截图：GitHub Copilot 应用中的“New worktree”下拉菜单，选项包括“New worktree”、“Local repository”和“Cloud”。然后，当你启动一个新会话时，点击顶部的会话名称，你会看到（有趣的）worktree 生成名称、路径、该 worktree 对应的项目，以及你所做更改的详细信息。

截图：上一步生成的 worktree。简单轻松，柠檬榨汁！

我应该使用 Worktrees 吗？

我会给你最资深开发者的答案：看情况！你可能更喜欢某种工作方式。你可能并行工作不多，更喜欢分支和 stash 的心智模型。你可能从今以后只使用 worktrees。也可能两种都用！

世界是你的牡蛎，今天就可以在 GitHub Copilot 应用（https://github.com/features/ai/github-app?utm_source=blog-git-worktree&utm_medium=blog&utm_campaign=github-copilot-app-ga-2026）中尝试它们。

作者

Cassidy Williams Cassidy 是 GitHub 开发者倡导团队的高级总监。她喜欢构建软件、为初创公司提供建议，并教开发者如何构建更好的产品。她每周发布一份新闻通讯，地址是 cassidoo.co/newsletter，你可以在那里获取她的更新、练习编程问题，以及收件箱里的一则笑话！

相关文章

Git 2.55 亮点（https://github.blog/open-source/git/highlights-from-git-2-55/）

开源 Git 项目刚刚发布了 Git 2.55。以下是 GitHub 对自上次发布以来一些最有趣的特性和变化的观察。

从 GitHub 探索更多

文档

文档

掌握 GitHub 所需的一切，汇集一处。

访问文档（https://docs.github.com/）

GitHub

GitHub

在 GitHub 上构建未来，这里是任何人从任何地方构建任何东西的地方。

开始构建（https://github.com/）

客户案例

客户案例

了解那些使用 GitHub 构建产品的公司和工程团队。

了解更多（https://github.com/customer-stories）

GitHub Universe 2026

GitHub Universe 2026

今年 10 月 28-29 日，在旧金山或线上参加 GitHub Universe，我们的旗舰开发者活动，汇聚人类、Agent 和世界代码。

立即注册（https://githubuniverse.com/?utm_source=Blog&utm_medium=GitHub&utm_campaign=module_uni_26）