Git Worktree 入門 — 不用 stash 的多分支並行開發
Git 工作流進化 第 1 / 1 篇
本篇是「Git 工作流進化」系列的第 1 / 1 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。
背景
你有沒有遇過這種情況：正在改一個 feature 改到一半，PM 突然說線上有 bug 要修。
傳統做法通常是：
git stash暫存手上的改動git checkout hotfix-branch- 修完 bug，commit，push
git checkout feature-branchgit stash pop把改動拿回來- 然後發現 stash 衝突了…
或者更暴力一點：直接 commit 一個 WIP: 先存一下 的 commit，之後再 squash。這兩種做法都不理想 — stash 容易忘、WIP commit 污染歷史。
什麼是 Git Worktree
Git worktree 讓你把同一個 repo 的不同分支，同時 checkout 到不同的目錄。
# 你的主要工作目錄
~/projects/my-app/ ← main branch
# 建立一個 worktree 來修 hotfix
git worktree add ../my-app-hotfix hotfix/urgent-fix
# 現在你有兩個目錄，各自獨立
~/projects/my-app/ ← 繼續改 feature（不用 stash）
~/projects/my-app-hotfix/ ← 修 hotfix重點：兩個目錄共享同一個 .git。commit history、remote、config 都是同一份。但工作目錄是獨立的，不會互相干擾。
基本操作
建立 worktree
# 從既有分支建立
git worktree add ../my-app-hotfix hotfix/urgent-fix
# 建立新分支 + worktree（一步到位）
git worktree add -b feature/new-thing ../my-app-new-feature列出所有 worktree
git worktree list
# /Users/bobo/projects/my-app abc1234 [main]
# /Users/bobo/projects/my-app-hotfix def5678 [hotfix/urgent-fix]刪除 worktree
# 先刪目錄，再清理
rm -rf ../my-app-hotfix
git worktree prune
# 或一步搞定
git worktree remove ../my-app-hotfix什麼時候該用 Worktree
| 情境 | 傳統做法 | Worktree 做法 |
|---|---|---|
| Feature 改到一半要修 hotfix | stash → checkout → pop | 開新 worktree，直接修 |
| 同時跑兩個分支的測試 | 切來切去 | 兩個目錄各跑各的 |
| Code review 時想看完整的分支 | checkout 過去看 | 開 worktree，用編輯器直接開 |
| 比較兩個分支的行為差異 | 切來切去或用 diff | 兩個目錄並排開 |
注意事項
- 同一個分支不能同時 checkout 到兩個 worktree — Git 會阻止你
- node_modules 不共享 — 每個 worktree 要各自
npm install（但這也是優點，環境完全獨立） - 命名慣例 — 建議 worktree 目錄放在主 repo 旁邊，用
{repo}-{用途}命名
反思
技術面
Worktree 從 Git 2.5（2015 年）就有了，但很多人不知道。原因很簡單：大多數 Git 教學不會教它，因為它不是「基礎操作」。但一旦你的工作流需要頻繁切換分支，它的價值就顯現出來了。
心態面
stash 用久了會覺得「就是這樣嘛」，但其實每次 stash 都有認知負擔 — 我 stash 了什麼？有幾個 stash？pop 會不會衝突？Worktree 的做法是從根本上消除這個問題：不需要暫存，因為你根本不需要離開。
有趣發現
很多 AI coding 工具（像 Claude Code）也開始支援 worktree 模式，讓 AI 在獨立的 worktree 裡工作，不影響你手上正在改的程式碼。這個概念和人類開發者用 worktree 的理由完全一樣 — 隔離。
