拒绝 Stash 混乱：Git Worktree 助你开启“多线程”开发神技
背景
昨天看codebuddy cli的文档时，看到了使用 Git Worktrees 运行并行 CodeBuddy Code 会话，我还没使用git worktree，决定了解一下这个功能。
什么是 Git Worktree？—— 给你的项目多开几张“办公桌”
在传统的 Git 工作流中，一个仓库（Repository）通常对应一个工作目录（Working Directory）。这意味着如果你想切换任务，就必须在同一个文件夹里切来切去。
Git Worktree 的出现打破了这种“单线程”限制。它允许你在同一个仓库下，同时开启多个物理上的工作目录。
如果把你的项目比作一个办公室，传统的开发模式是只有一张办公桌，换任务就得清理桌面。而 Git Worktree 则是为你多开了几张办公桌，每张桌子上都摆着同一个项目的不同分支，但它们共用同一个“档案柜”（即.git文件夹）。你在任何一张桌子上提交的代码，档案柜都会实时同步。
如何使用 Git Worktree？—— 三行命令搞定任务分身
掌握 Worktree 并不复杂，你只需要记住这三个核心动作：
1. 开辟新战场：添加工作树
假设你正在 feature 分支工作，突然需要去修复 main 分支的 Bug。你可以在同级目录下创建一个名为 hotfix-repo 的新目录：
1 | # 在当前项目目录下执行 |
如果你想直接创建一个新分支并开启工作树，只需加上 -b 参数：
1 | git worktree add -b emergency-fix ../fix-dir master |
2. 查阅分身：列出所有工作树
想知道自己当前开了多少个”平行时空”？
1 | git worktree list |
3. 功成身退：移除工作树
当 Bug 修复并合并后，你可以安全地销毁这个临时目录：
1 | git worktree remove ../hotfix-repo |
三、为什么不直接用 Stash 或多克隆一份？—— 核心方案大横评
很多开发者会问：“我用 git stash 暂存一下，或者直接 git clone 两个文件夹不也能并行吗？”
通过下表对比，你会发现 Worktree 在“联动性”和“成本”之间找到了完美的平衡点：
| 特性 | git stash | 手动克隆两个文件夹 | git worktree |
| ——– | ——————————- | —————————- | —————————— |
| 工作模式 | 串行（必须先存起 A 才能做 B） | 并行（完全独立，互不感知） | 并行（高度联动，数据共享） |
| 切换成本 | 高（需要清理现场、重新装依赖） | 低（直接点开另一个文件夹） | 极低（秒级创建，无需重装） |
| 磁盘占用 | 最小 | 最大（重复存储所有历史记录） | 小（仅增加代码文件，共享历史） |
| 同步方式 | 无需同步 | 必须通过远程仓库 push/pull | 本地实时共享，直接 merge |
| 典型痛点 | 容易忘记 stash 了什么，环境易乱 | 浪费硬盘，多个副本间同步极慢 | 唯一限制：同分支不能双开 |
四、如何更高效地使用？—— 职业开发者的”多线程”秘籍
学会了命令只是开始，真正的效率提升来自于工作流的优化：
1. 终端多 Tab 联动
不要在一个终端窗口里来回跳。为每个 Worktree 开启一个独立的终端标签页（Tab）。
- Tab 1： 跑着
feature分支的长耗时单元测试。 - Tab 2： 在
hotfix目录里快速修改代码并提交。这种物理上的隔离能让你的“思维上下文”非常清晰，命令历史记录也不会互相污染。
2. IDE 多窗口并行
在 VS Code 或 IntelliJ 中，同时打开两个窗口。左边是功能开发，右边是 Bug 修复。由于文件夹路径不同，你可以为不同的工作树配置不同的调试环境或环境变量，甚至可以同时运行两个不同版本的服务进行对比。
3. 彻底解决”依赖地狱”
在前端开发中，切换分支往往意味着要重新运行 npm install。使用 Worktree 后，每个目录都有自己独立的 node_modules。你再也不用因为切个分支修 Bug，就花 5 分钟等待依赖下载了。
4. 定期”修剪”仓库
如果你手动删除了工作树目录（而不是通过命令删除），记得运行：
1 | git worktree prune |
这会清理掉 .git 数据库中那些已经失效的路径引用，保持仓库的健康。
总结
Git Worktree 不仅仅是一个命令，它代表了一种“不中断、不等待、不浪费”的开发哲学。当你习惯了在多个工作树间自由穿梭，你会发现自己处理紧急任务的焦虑感大大降低，开发节奏也变得更加丝滑。