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。这样全局记忆更容易连续，如果一个需求要同时改多个项目，它也知道怎么逐个改完，再联合测试。