最近开发一个项目时，我碰到了一个挺麻烦的情况。
之前一直在 A 分支上做一套业务功能，和 Codex 聊了很久，对话里已经积累了大量业务上下文。代码后来也合并进 main，正式上线了。
但上线不代表这部分功能就不用改了。原来的功能还需要继续完善，同时又要在它的基础上开发一个变化比较大的版本，于是我又开了 B 分支。
麻烦就出在这里：A 分支后面可能随时要修问题、改功能，修改后还会合并到 main。B 分支正在开发的新功能，又有不少地方需要以 A 的最新业务逻辑为准。
一个工作目录来回切分支，太容易乱
如果只用原来的工作目录，就可能出现这样的情况：
我正在让 Codex 开发 B 分支的功能，任务还没执行完，突然又需要回去修改 A 分支准备上线的代码。
这时既要处理正在进行的修改，又要切换分支。等 A 的事情结束，再回到 B 继续开发。过一会儿 A 可能又有新的问题。
光想想就头疼。
而且我还不想丢掉 A 分支里积累的长对话。里面有很多之前反复沟通过的业务背景，重新给 Codex 讲一遍也挺费劲。
我用 /fork 配合 Worktree 把两边分开
后来我用了 Codex 的 /fork，从原来的对话创建一个新聊天。新聊天能够继承之前的对话历史，我就不需要重新解释一遍业务背景。
接着让新聊天在独立的 Worktree 工作目录里开发 B 分支。我这次操作下来，新窗口对应了新的工作目录，我直接用 IDEA 打开它，就可以在里面继续开发。
这里有两个容易混在一起的概念：/fork 处理的是 Codex 对话历史，Worktree 处理的是 Git 工作目录。两者配合使用，才适合我这次的场景。实际创建 Worktree 的入口和步骤，还要以自己所用的 Codex 版本为准。
这样一来，原来的目录继续处理 A 分支，新目录负责 B 分支。两边代码不会因为我在同一个目录里切换分支而互相打断，Codex 也可以分别继续各自的任务。
A 分支又有改动怎么办？
这两个分支毕竟还有关联。A 修完问题后，我会按原来的流程把修改合并到 main。
之后切回 B 对应的 Codex 聊天，告诉它 main 已经更新，需要检查并同步相关代码。
这一步我会让它先获取远程更新，再根据 B 分支目前的开发情况处理合并。单独执行 git fetch 只能拿到远程更新，代码不会自动进入 B 分支，仍然需要合并或者采用其他合适的方式整合，遇到冲突也要处理。
至少不用中断 B 的整个工作环境，再跑回同一个目录来回折腾了。
这次用下来确实省了不少麻烦
我以前知道 Git Worktree，但一直没有在这种场景下认真用过。最近开发任务越来越依赖 Codex，才发现它和 /fork 放在一起挺实用。
特别是原来的业务上下文已经很长，新旧功能又需要并行推进的时候，能保留聊天历史、把工作目录分开，对我来说帮助很大。
当然，两个目录并不代表代码会自动同步。A 的修改什么时候合并到 B、冲突怎么处理，仍然要看实际情况。
这次至少解决了我眼前最烦的一件事：B 分支开发到一半时，即使 A 分支突然要改，我也不用把正在做的工作全部停下来切来切去了。