前一阵大家常见的用法，是先准备好一个 worktree，再在那个目录里打开 Codex / Claude Code。
前一阵大家常见的用法，是先准备好一个 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。这样全局记忆更容易连续，如果一个需求要同时改多个项目，它也知道怎么逐个改完，再联合测试。
页:
[1]