Worktree 更適合作為一次性的執行目錄

前一陣大家常見的用法，是先準備好一個 worktree，再在那個目錄裡打開 Codex / Claude Code。因為早期模型的上下文和記憶不夠穩，如果直接在 main workspace 裡讓它自己建立 worktree，很容易在上下文壓縮後混淆當前目錄和它建立出來的 worktree 目錄，最後改亂。
但這種用法也有個副作用，就是會慢慢把 worktree 用成一個長期工作空間。問題是 worktree 本來就是綁定分支的，時間一長，你遲早會在裡面遇到切分支、同步分支、清理分支這些額外麻煩。
Worktree 和獨立 clone 的區別，很多人其實也沒有特別分清。它的好處不是“多一個目錄”，而是它本質上還是同一個 repo，共享 git object 庫，複製成本低，也不需要重新走一遍網路 clone。這對大倉庫尤其方便。所以如果你只是想臨時拉一個並行執行目錄，worktree 很合適。只有在你明確需要一個完全獨立的 object 庫，比如要映射到 docker 或虛擬機沙箱裡時，local clone 才更合適。
至少對現在的 Codex / Claude Code 來說，這個問題已經沒那麼嚴重了。我現在更傾向於直接在 main 目錄裡工作，讓它按需要去建立 worktree，改完合併回來，再把 worktree 清掉。這樣更符合 worktree 本來的定位：低成本的臨時執行目錄，而不是長期駐留的第二工作區。
再往前一步，我現在正在嘗試的一種方式，是維護一個全域 workspace，所有專案的 Codex 都在這個目錄打開，然後讓它自己按規則管理 clone 和 worktree。這樣全域記憶更容易連續，如果一個需求要同時改多個專案，它也知道怎麼逐個改完，再聯合測試。