git 进阶之路：从 stash 到 worktree

0X00 背景

我们程序员最理想的开发流程一定是切出分支，开发完成，合并代码，再切新分支写新代码。但事情往往不是这样的，但凡你在一个超过 5 人的项目组中工作过就会遇到过这种情况：正在某个 feat/xxx 分支开发呢，突然需要临时搞一个 hotfix，或者突然有人问你某某分支里的业务逻辑是怎样的，这种场景是极其常见的。该怎么办呢？

0X01 学会 stash

如果你刚开始用 git 没多久，那多半是没什么办法，毕竟总不能把现在写了一半的代码改回去吧。然后你去网上搜（当然了，在 2026 年大概率是问 AI），莫名其妙看到了类似这篇文章的东西，现在你学会了使用 stash 命令。你成功的把当前做了一半的事情“暂存”了起来，然后切到对应的分支开始另一件事的开发。

这其实是很多人的路径，并且一度认为 stash 真的是个好东西，尤其是了解 stash save 之后，已经能解决大多数这种场景的需求了。

但现在事情发生了变化。

0X02 在 AI Coding 时代直接尬住了

AI 时代来了，有一天你正在用 Claude Code 在 feat/xxx 分支疯狂开发，Claude 已经在 Opus max 模式下工作了十多分钟了，还在深度思考。突然你要搞一个 hotfix 或者调研某个分支。按照原来的方案你可以快速 stash，解决问题后再切回来继续写代码。但是你在 stash 前的一瞬间反映过来： Claude 正在工作，你 stash 了就意味着要打断 Claude 的进程。

聪明如你（反正我当时是这么处理的），可能会考虑直接再 clone 一遍仓库或者直接把现在的仓库复制一份，这样一来可以在新仓库里操作，操作完再删掉。但实际上 git 早在 10 年前就引入了一个叫做 worktree 的东西解决这个问题。

0X03 使用 worktree

假设有一个项目 project-A 放在 ~/Workstation/project-A，我们在 feat/xxx 分支进行开发，这时候可以使用 git worktree add -b fix/xxx ../project-A-fix-xxx master 的命令。这时候你的 project-A 的同级目录就会出现一个 project-A-fix-xxx 的目录，这个目录就是一个 worktree，它和你的主 worktree 也就是 project-A 目录共享 .git 文件（也就意味着当你在 project-A-fix-xxx 上做了 commit 之后，在 project-A 是可以直接看到的，不用 git pull）。

这样做的好处：

• 对比 stash 方案，不会打断 Claude 现在的工作进度，甚至你可以多线同时开发多个分支，最后 merge 到一起
• 对比 clone 方案，不会出现两个或者多个代码库（节省空间），而且不需要在一个目录里 push 后再到另一个目录里 pull

基于某个分支创建新 worktree 和 branch 的命令格式是 git worktree add -b <新分支名> <新目录路径> [起点分支/commit] 创建一个新的 worktree 并切换到一个现有的 branch 的命令格式是 git worktree add <新目录路径> <已有分支名>

其他的 Tips：

• 如果不再需要某一 worktree 了，可以使用 git worktree remove ../project-A-fix-xxx 的方式删掉
• 使用 git worktree list 可以看到自己创建了的 worktree
• git 暂时没有提供使用 git 命令在多个 worktree 之间跳转的方法，还是需要自己管理每个 worktree 的位置，自行跳转
• worktree 的位置没有严格要求，但是约定俗成的方式都是将它放在和主 worktree 同级的目录里，并使用仓库名作为目录名的前缀

0X04 最后

没那么多“最后”，只是说 worktree 这个技能从早些时候的“高阶技能”已经变成大家最好都要掌握的东西了。另外你说我文章里没写清楚用法？那去问 AI 呀，现在 AI 这么发达，大家最不缺的就是详细了解一个东西（尤其是这种通用工具）用法的途径，而是“不知道还有这个东西存在”，这也正是我写博客的所剩不多的动力之一。