用 Git Worktree 讓多個 Claude Code 並行開發

這篇想記錄一個我最近在用的工作流程：用 Claude Code 搭配 Git Worktree，同時推進多個 issue 的並行開發。

會想寫，是因為我在學 AI coding 的路上，是漸進式地熟悉、慢慢放手讓 AI 工作的。目前大概到了能驅使多個 session 並行跑的程度，覺得這個過程值得記下來。

從「把 AI 當 Google」到放手讓它自主開發

回頭看，我用 AI 協助 coding 大致經歷了這幾個階段：

1. 初期：把 Claude Code 當成另一種 Google。問它怎麼寫、跟它討論，但 code 仍然自己手寫。
2. 局部代寫：開始用 prompt 請 Claude Code 幫我改局部的程式碼。
3. 規劃與實作分離：學會控制載入 context 的相關性。先跟 Claude 討論、做規劃，請它把規劃內容寫下來；接著另開一個 session，讓它讀取先前寫好的規劃再實作。這樣可以避免 context 過大、或混入不相關的內容造成污染。
4. 交付周邊雜事：在實作之外，開始把自動化測試、git commit 這類瑣事也交給它。
5. 授權自主流程：前面幾個階段本質上都還是在單一 session 裡一來一往的線性開發。但經驗累積夠了之後，我對它的能力邊界有了足夠的信心，開始敢授權它自主執行整段任務——需求規劃好之後，讓它自己實作、測試、commit，甚至把 code review 也納入流程。

走到第 5 階段會出現一個新狀況：Claude Code 一次自主流程可能要跑上幾十分鐘。如果我還是用線性的方式開發，這段時間就只能坐在電腦前看它表演、等它回應——而這段時間其實可以利用起來。

一段自主開發的 prompt

下面是我用來觸發這種長時間自主開發的 prompt 範例：

1. 讀取 GitHub 看板卡片 #{Number}，理解需求
2. 啟動 subagent 實作，完成後 commit
3. 進入「審查—修正」迴圈：
   - subagent 執行 /code-review --fix
   - 有改動就 commit，重複直到不再產生改動
   - 迴圈上限 10 次，超過即停下，等我釐清無法收斂的原因
4. 迴圈收斂後，執行 /simplify 精煉整體改動：
   - 有改動就 commit，並再跑一次 /code-review 確認沒有引入新問題
5. 全部通過後，push branch 並發起 PR
6. 對 PR 執行 /code-review #{PrNumber} --comment，將發現的問題留言備查
 
每一步都回報「做了什麼、動了哪些檔案」。

幾個說明：

• 讀取 GitHub 看板卡片走的是 GitHub 官方的 gh CLI，所以 Claude Code 能直接抓卡片內容、發 PR。
• /code-review 和 /simplify 是 Claude Code CLI 的內建指令，分別負責找問題並修正、以及精煉整體改動。
• 把迴圈上限設在 10 次，是怕它在無法收斂的改動上反覆打轉；超過就停下來,留給我判斷原因。

為什麼要並行：把不相關的工作拆開

有了能自主跑幾十分鐘的流程，下一個問題就是怎麼不浪費這段等待時間。

關鍵在於拆規格、做規劃的時候，順手看看有沒有哪些工作其實彼此不相關。那些不會互相阻擋的任務，就可以並行地開發，最後再各自 merge 回來。

要做到並行，可以用 Git 的 worktree 功能。

用 Git Worktree 開出獨立工作目錄

# 列出目前所有 worktree
git worktree list
 
# 從 master 建立新的 worktree，同時開一條新 branch
git worktree add ../shangwang-dev-feat-foo -b feat/foo master
 
# 工作結束後移除 worktree，並清掉殘留的 metadata
git worktree remove ../shangwang-dev-feat-foo
git worktree prune

簡單來說，建立 worktree 時會把 repository 的工作目錄「複製」一份出去；但 Git 的核心資料（也就是收錄 commit 節點的那些資訊）並沒有跟著複製，新的 worktree 只是持有一個 reference，指回原始 repository。

所以當你在某個 worktree 裡 commit 時，節點其實是回寫到原本那一個 Git repository。這帶來兩個好處：多個 worktree 共用同一份 commit 歷史，你在本機就能即時看到不同 worktree 的進度；同時各個 worktree 在不同 branch 上工作，彼此不會互相干擾。

Worktree 的坑：local-only 檔案不會被帶過去

用 worktree 有一件事要注意：那些只存在 local、不會 commit 進 repo 的檔案——像 CLAUDE.local.md、.env.local 之類——在建立 worktree 時並不會被複製過去。

我的解法是請 Claude 做一個管理 worktree 的 skill，把對應的 scripts 寫進去。之後我就能直接用這個 skill：請它依照看板卡片的規劃內容建立 branch，同時把那些 local-only 的檔案複製到新的 worktree 目錄。等多個 worktree 工作結束，也能讓 Claude Code 用同一個 skill 幫我批次移除不再使用的 worktree 目錄與 branch。

我的實際並行流程

在整理這篇 post 之前，我就是用並行開發的方式，同時做了這個 blog 的幾個功能：

1. code block 補上複製內容的按鈕與功能
2. 替 post 抽出段落標題，做成左側的 sticky 目錄列表
3. 在 posts 列表補上標籤雲計數功能
4. 在文章最下方加上新／舊文章的導覽按鈕

流程是這樣的：

先在 GitHub 的 Kanban 上開四張對應的 issue，每張只有一句話的標題，描述我想要的功能。接著在停在 master branch 的主專案裡開一個 Claude session，告訴它卡片編號，開始討論這張卡片要做什麼、請它規劃，讓我 review 做法是否符合預期，再請它把確認過的做法與規劃寫回 issue 卡片裡。

寫完第一張卡片後，我就請它幫我建立對應的 worktree branch，然後另開一個 Claude Code session，用前面那段 prompt 的流程去實作、code review、發 PR。在它執行的這段時間，我就回到主專案開始討論下一張 issue；討論完同樣開新的 worktree branch、交給另一個 session 去做，以此類推。

等第一個任務全部完成、PR 發出來，我就上 GitHub 看完整的改動，做一次「人類的」code review。而這個時候，其他 worktree branch 裡的 Claude Code 可能都還在實作。靠這種方式就能讓多個任務並行推進，而不必在 Claude Code 長時間實作時無事可做、乾等它表演。

接下來：更進一步放手

目前因為我還在學 React、Next.js 和 TypeScript，所以仍然會逐行讀 Claude 幫我寫出來的程式碼，藉此理解細節。不過我猜，那些重複模式的程式碼片段應該會越看越快，從逐行閱讀慢慢變成區塊閱讀；到後面或許只需要看資料的流向、元件的拆分、依賴方向、安全性這類問題，不再需要逐行去摳語法細節。

這種並行開發的方式，也在一步步建立我對 AI 的信心與熟練度。再往前一步，或許就是直接啟用 Claude Code 的 /loop 功能：定期去特定的 GitHub 看板檢查有沒有新 issue 進來，有的話就自動判斷相依順序，直接開始實作。

那樣的話，未來說不定會變成——我們只在專案這邊討論 issue 卡片，請 Claude 幫忙把 issue 推上去；後面就交由 Claude Code 自動捕捉 issue、實作、發 PR。