Worktrunk 值不值得裝：同時跑幾個 agent、專案有多重的 gitignored 產物，兩個問題先答完

三個 coding agent 開在同一個目錄裡，一個改到一半還沒 commit，另一個要換分支做別的事。Worktrunk 的 FAQ 對這個局面講得很直接：切分支只有一個目錄，一個 agent 沒提交的變更會混進下一個 agent 的工作，要不然就乾脆擋住切換。解法是每個 agent 一個 worktree，各有各的檔案和 index。

這個解法 git 本身就有。所以真正要問的是：要不要為了 worktree 再裝一個工具？我先講我的答案，再講理由：同時跑的 agent 不到三個，手打 git worktree add 就夠，不用往下看。三個以上，而且每個 worktree 都得重裝依賴、重編譯，才輪到它開始回本。三這個數字是我自己抓的門檻，文件沒有給。README 的說法是 5 到 10 個以上平行「是可能的」，那是概述句，沒附量測。

先交代這篇的底：我只讀了文件，沒有實際裝起來跑過。下面所有「它會怎樣」都是作者文件或原始碼倉庫裡寫的，不是我跑出來的。

它多出來的東西，和你手上的指令差在哪

README 給了一張對照。建立 worktree 並直接啟動 Claude：

1
2
3
4
5

# Worktrunk
wt switch -c -x claude feat

# 純 git
git worktree add -b feat ../repo.feat && cd ../repo.feat && claude

收尾也是一行對兩行：wt remove，對上 git worktree remove ../repo.feat && git branch -d feat。平行開三個 agent 的寫法，README 的 Quick start 是這樣：

1

wt switch -x claude -c feature-a -- 'Add user authentication'

-x 是切過去之後執行指令，-- 後面的字串會傳給那個指令。feature-b、feature-c 照同一個形狀重複。

光是這樣，手寫個 shell function 就能追平，所以我不覺得指令縮短是理由。FAQ 列的「git worktree 不提供的東西」才是：目錄命名一致與清理前的檢查、專案層級的自動化（裝依賴、啟動服務）、跨 worktree 的統一狀態（commit、CI、衝突、變更）。wt list 能一眼看完整排，git worktree list 只給路徑。issue #3454 有位使用者從另一個 worktree 工具轉過來，說用了 wt list 之後回不去了，因為同時顧十幾個 worktree 變得一目了然。那是一個人的回報，而且同一則 issue 其實在抱怨：他想念舊工具的設定管理。

回本的那一格：被 gitignore 的大東西

新 worktree 是乾淨的 checkout，node_modules、target/ 這些被 gitignore 的產物不會跟過去。每開一個 agent 就重裝一次依賴、重編一次，三個 agent 就是三份，這才是 worktree 工作流真正的成本。

Worktrunk 的對策是 wt step copy-ignored，把主 worktree 裡被忽略的檔案複製到新的那一個。FAQ 的說法是，在 APFS、btrfs、XFS 上它走 reflink，新 worktree 和主 worktree 共用磁碟區塊。文件給的數字如下，全是作者文件自述，我沒有實測，也沒查他們用什麼機器：

文件另外補了一句：reflink 是逐檔進行的，和 cp -Rc 一樣，複製時間會隨檔案數量增加。node_modules 那種小檔特別多的專案，20 秒這個數字大概不能直接套。這句是我的推論，文件沒有給 node_modules 的數字。

這一格決定了整件事該不該裝。專案沒有重的 gitignored 產物，或你本來就每次都想從乾淨狀態重裝，複製功能就是用不到的零件。

會讓它失效的條件

README 的口氣是推薦，不適用的條件散在 FAQ 和 docs 各處，我把它們撈出來放在一起。

第一個是檔案系統。FAQ 明寫 ext4 和 NTFS 不在 reflink 清單上，docs/step 那頁說這兩種檔案系統「沒有 reflink，每個檔案都完整複製」。所以前面那張表的 20 秒，在 ext4 上不會發生，Windows 的 NTFS 也一樣。你的 agent 若跑在 ext4 的雲端機器或 NTFS 的 Windows 上，copy-ignored 就退化成一般複製，14GB 就是真的複製 14GB。

第二個是 stacked branches。FAQ 的回答是原生不支援，作者把它當成擴充而不是內建功能，並指向社群工具 worktrunk-sync，那個工具現在狀況如何我沒查。issue #1983「Stacked branches」從 4 月 7 日開到我查的時候仍是 open，有 11 則留言。如果你的流程是一串疊起來的分支，這個工具目前要另外湊。

第三個是預設連 .env 一起複製。docs 寫的是「所有 gitignored 檔案預設都會複製」，要限縮就建一個 .worktreeinclude，檔案必須同時「被 gitignore 且列在裡面」才會複製。Worktrunk 的文件拿 Claude Code 對照，說它要有 .worktreeinclude 才複製（這是 Worktrunk 文件的說法，我沒對過 Claude Code 現況）；Worktrunk 這邊加 --require-include 可以對齊那個行為：

1
2

# 只複製 .worktreeinclude 列出的檔案
wt step copy-ignored --require-include

docs 把 .env 列在會複製的環境檔裡。意思是你的祕密檔，在你沒設限的情況下，會被複製進每一個 agent 的工作目錄。我自己的取捨是：只要專案的 .env 裡有正式環境的金鑰，第一件事就是建 .worktreeinclude，或直接加 --require-include。

第四個是系統條件。要 Git 2.43 以上。Windows 要裝 Git for Windows，因為 hooks 用 bash 語法、經由 Git Bash 執行，即使你平常用 PowerShell。wt 這個名字還會和 Windows Terminal 的指令撞，winget 版因此裝成 git-wt。issue #3355 裡有人回報 winget 版的 git-wt.exe 被 Windows Defender 判成木馬，只有他一個人說，我沒驗證是不是誤判，也沒查後續。用 Cargo 裝則需要 C99 編譯器，否則要加 --no-default-features --features cli。

第五個是它會往你機器上寫東西。wt config shell install 會在 bash、zsh、PowerShell 的 rc 檔加一行；fish 和 Nushell 是寫自己的 wrapper 與補全檔。倉庫內有 .git/wt/（快取、日誌、trash）、git config worktrunk.*、refs/wt-backup/<branch>（squash 備份）。若你執行 wt config plugins claude install-statusline，它會把一個 statusLine 項合併進 ~/.claude/settings.json。FAQ 同時寫明沒有常駐程序、沒有全域 git hooks、不改 ~/.gitconfig。這些都不算嚴重，但如果你很在意 rc 檔和 Claude Code 設定檔的乾淨，要先知道。

刪除與 hooks：兩道閘門和各自的洞

wt remove 對有未提交變更（含 untracked）的 worktree 會拒絕，--force 才會硬刪並丟掉那些變更；預設只刪「內容已在預設分支」的分支，-D 才能強刪。要保護放著本機資料庫的 worktree，FAQ 建議用 git 自己的鎖：

1

git worktree lock ../repo.feat

文件說被鎖住的 worktree，包括 Worktrunk 的任何刪除路徑，連 --force 都刪不掉。issue #4544「Stash on wt remove -f」是 10 月 21 日開的，我查的時候還是 open，沒有結論，所以 -f 丟掉變更這件事目前就是照字面執行。

專案 hooks 這邊，FAQ 說專案 hooks 與 aliases 的指令第一次執行要人工核准，核准結果存在 approvals.toml，指令一變就要重新核准。同一段也寫了 --yes 可以略過，文件的用途說明是給 CI 與自動化。我沒查除了 --yes 之外有沒有其他略過方式。自動化流程裡有人把 --yes 寫死，那道核准就等於沒有，要審的是那行設定。

0.x 版的代價

最後一個條件是版本。我查的時候 stars 是 9373，最新版 v0.81.0 在 10 月 20 日發布，前面四版依序是 9 月 27 日、9 月 21 日、9 月 16 日、9 月 8 日。九月那四版之間隔五到八天，最近一版隔了二十三天。更新頻繁對想要新功能的人是好事，對寫了一堆自訂 hooks 的人不是：v0.81.0 的 release notes 標了兩項破壞性變更，hooks 不再用 stdin 收 JSON 格式的 context，模板改用 MiniJinja 3，物件和清單的輸出變成 Python 風格（{'port': 3000}）而不是 JSON。Nushell 整合也要求 0.113 以上。

授權的部分順手釘一下。GitHub API 的 license.spdx_id 回的是 NOASSERTION，那是因為 LICENSE 檔是雙授權的合併檔，內文寫「dual-licensed under MIT and Apache-2.0」，Cargo.toml 第 66 行是 MIT OR Apache-2.0。所以 API 回 NOASSERTION 不是缺值，是兩者擇一。

還有一個我不會替它背書的句子：README 說它「quickly become the most popular git worktree manager」，這是作者自己的評語，我讀不到第三方排名可以對照。

判準與會讓我改變想法的條件

把前面收成一張表。這是我讀完文件後自己下的判斷，文件沒有這樣推薦：

Claude Code 也有自己的 worktree 旗標。這篇我沒有重查現況文件，手上只有 10 月 15 日留下的快取，所以不拿它來比功能；你若只想要「隔離」這一件事，用之前自己對一次它現在的行為。

會讓我改看法的條件有三個。有人拿到 ext4 或 NTFS 的實測，證明沒有 reflink 時它的複製與 hooks 仍然比自己寫的腳本划算，那張表的第三列就要改。作者數字被第三方在別的機器上重現，那三個數字才能從「文件自述」升級成我敢直接引用的東西。第三個是版號到 1.0 且 hooks 語法穩定，到那時「0.x 破壞性變更」這一條就可以從不適用清單劃掉。

反過來，如果有人跑出來說 copy-ignored 在大型 node_modules 上也是秒級，我的推論就是錯的，這一節要重寫。

我讀了什麼、沒做什麼

讀的是 gh api 取得的倉庫元資料、releases、issues、LICENSE、Cargo.toml、README 與倉庫內的 docs 原始檔（faq、step、tips-patterns）。沒有裝 Worktrunk，沒有跑任何 wt 指令，沒有在任何檔案系統上量過 reflink，也沒有逐頁比對渲染後的官網。表裡的三個數字、「平行 5 到 10 個」都是文件自述。

帶走兩個問題就夠了：你同時跑幾個 agent，你的 worktree 每開一個要付多重的初始化。這兩個答案出來之前，裝不裝都只是猜。