Git Worktree 是什麼？為什麼 CCManager 要用它

很多人第一次看 CCManager，被「Git Worktree」這個詞卡住，然後把它當成 CCManager 的專有名詞——其實不是。Worktree 是 Git 原生功能，CCManager 只是把它跟 AI Agent 管理結合在一起。

這篇先把 Worktree 本身講清楚，後面操作起來才不會霧煞煞。

先說正常的開發模式有什麼問題

你平常開發可能是這樣：切到 feature-a branch 改東西，中途被叫去修一個 hotfix，只好先 commit 或 stash，切到 main，修完再切回來——繁瑣，而且 stash 管多了很容易亂。

AI Agent 多起來之後這個問題更嚴重。你想讓三個 Agent 並行，但它們全都要操作同一個工作目錄，誰改了誰的檔案會打架，根本跑不了。

Git Worktree 是什麼

用一句話說：Git Worktree 讓你在同一個 repo 裡，同時 checkout 多個不同的 branch 到不同的目錄。

git worktree add ../my-repo-feature-a feature/a
git worktree add ../my-repo-hotfix hotfix/urgent-fix

跑完之後，你的目錄結構長這樣：

~/projects/
├── my-repo/           ← 原本的 repo，在 main branch
├── my-repo-feature-a/ ← Worktree，在 feature/a branch
└── my-repo-hotfix/    ← Worktree，在 hotfix/urgent-fix branch

三個目錄，三個 branch，完全獨立——改 my-repo-feature-a 的檔案，不影響 my-repo。可以同時開三個終端機，各自在不同 Worktree 跑指令，互不干擾。

底層共用的是同一個 .git 物件資料庫，所以不是複製整個 repo，空間用量很省。

為什麼 CCManager 要建在 Worktree 上

這就是關鍵。

每個 AI Agent 工作階段需要一個獨立的工作環境——自己的 branch、自己的工作目錄、自己的 Claude 對話歷史。如果全部擠在同一個目錄裡，Agent A 改了 utils.ts，Agent B 不知道，兩個人改同一支檔案，最後誰的存下去都是個謎。

Worktree 解決了這個問題：一個 Worktree 對應一個 AI Agent 工作階段，各自有獨立的工作目錄，Agent 之間完全隔離。

CCManager 的角色是：從同一個介面管理所有 Worktree 上跑的工作階段，讓你不用一個一個切換目錄，也能知道每個 Agent 目前的狀態。

工作階段資料可以複製

有個很實用的功能：建新 Worktree 的時候，CCManager 可以幫你把 Claude Code 的工作階段資料（對話歷史、專案上下文）複製過去。

這樣你在 main 跟 Claude 講了一大堆背景，切到新的 feature branch 時不用重新介紹——Claude 在新 Worktree 知道你們之前說了什麼，可以直接繼續。

這個行為可以在 Global Configuration → Configure Worktree 裡設定預設值，也可以每次建 Worktree 時單獨選要不要複製。

一個常見誤解

Worktree 和 clone 是不同的。

git clone 是把整個 repo 複製一份到新地方，有獨立的 .git 資料夾，跟原本的 repo 是分開的個體。

git worktree add 是在同一個 .git 下開新的工作目錄，共用底層資料，只是 checkout 到不同 branch。它更輕量，也不需要再設定 remote。

概念清楚了，下一篇就是實際操作：建立、切換、刪除 Worktree：CCManager 的核心操作。

從 CCManager 介面建 Worktree、把 Agent 放進去、跑完合回主線——全部流程在那裡。