Git Worktree 与 Git Branch 开发的差异是什么？在什么情境适合使用 Git Worktree 开发？

开发新功能开发到一半，突然老板跑来说有紧急 Bug 要修，你会怎么办？

大部分的人应该都是先 git stash 把刚写一半的 code 塞进柜子，然后切换分支去修 Bug。

但如果你改的东西涉及到大量的环境配置，或是切换分支后 node_modules 跟编译后的档案（Build Artifacts）会互相污染，那真的会让人想摔键盘。

这时候，Git Worktree 就是你的救星了！

什么是 Git Worktree？

你可以把 Git 的运作想像成「装修房子」。

传统的 git branch 当你切换分支时，房间里的家具瞬间在你眼前消失，然后自动摆放成另一个任务的样子。

虽然省空间，但缺点就是 「环境污染」。你得先把还没洗的碗盘塞进柜子，否则切不过去；而且切换后，空气中可能还残留着上一场工程的油烟味。

而 Git Worktree 则是直接在隔壁空地再盖一间一模一样的房子。

简单来说，Git 底层的原理就是：

「一个灵魂（.git 数据库），多个肉体（工作目录）」。

你可以同时拥有「功能开发店」和「紧急维修店」两个文件夹。左手在 A 窗口写 AI 逻辑，右手在 B 窗口修 Bug，两边互不干扰，这才是真正的并行开发。

要在开发时保持心流，目录结构跟环境配置是关键。

很多人第一次用 Worktree 会手残把新目录开在原本的专案文件夹内。千万别这么做！这会让 Git 陷入无限递归的混乱。正确的 Git Worktree 盖法是：

主基地（main）与任务分店（feature）平行放置。

# 在主基地执行建立 Worktree，但把 Worktree 目录建立在原本专案外面的目录
git worktree add ../my-app-feat-ai dev-branch

你的目录结构看起来应该像这样：

- my-project/       # 大型包裹
  - main-repo/      # 稳定的主基地
  - feat-ai-search/ # 正在施工的新分店

既然专案目录分开了，你的 .env 设定档也可以分开。

你可以在 feat-ai-search 连接测试用的数据库，而在 main 维持原本的开发数据库。这样切换窗口时，连连线信息都不用改。

进入 Worktree 目录后，直接使用该 Worktree 目录的环境变量进行开发，不用做任何的环境切换或重建整理，那种 「踩进去就开工」 的感觉真的非常爽。

在 Worktree 里开发完后，流程跟传统分支其实一模一样，只是多了一个「拆迁」动作。

步骤流程	说明
1. 在分店提交（Commit & Push）	你必须亲自走到分店现场才能签字。
2. 总部验收（Merge）	你可以回到 `main` 进行合并，或是直接发 Pull Request (PR)。
3. 优雅拆迁（Remove）	任务完成后，不要直接删除文件夹，要用 Git 指令来拆迁：`git worktree remove ../feat-ai-search`

轰！ Worktree 临时屋拆掉了，硬盘空间回来了，你的主基地依然干干净净。

Worktree 虽然好用，但还是有几个坑要注意：

项目	说明
主基地不要乱搬家	因为 Worktree 纪录的是绝对路径。如果你改了主基地的文件夹名称，Worktree 分店会因为找不到「灵魂」而暴毙。
分支不能双开	同一个 Branch 不能同时在两个 Worktree 被 Check Out。
扫地机器人 `prune`	如果你真的手残直接用 `rm -rf` 删了文件夹，记得执行 `git worktree prune` 把残留在 `.git` 上的纪录清干净。

不同的情境会使用不同的开发方式，没有谁取代谁的问题，只有适合不适合的问题。

情境	说明
日常小改动	继续用 `branch`，轻便快速。
跨度大的任务	比如大规模重构、跨多个环境变量的调整、或是需要跟 AI 长时间协作的任务，开一个 Worktree 绝对是首选。

Git Worktree 不仅是一项指令，更是帮助我们维持开发心流的利器。下次遇到麻烦的跨度任务，不妨替自己开一间独立的 「Git Worktree 分店」，感受那种从未有过的流畅开发体验吧！