这次事情，表面上是一个 Git 分支 tracking 配错的问题。
但我真正想记录的，不是 git worktree add 这个命令本身，而是我在使用 Codex 的时候，暴露出来的一个问题：
我太相信流程会自己正确了。
当时我想让 Codex 在一个独立的 worktree 里处理代码清理任务，所以创建了一个新分支：
git fetch origin master && \
git worktree add .worktrees/codex/test-code-cleanup \-b codex/test-code-cleanup origin/master
我当时的想法很简单：
基于最新的 origin/master，创建一个新的 worktree，然后让 Codex 在里面干活。
但问题就在这里。
Git 当时其实已经明确提示了：
branch 'codex/test-code-cleanup' set up to track 'origin/master'.
这句话我没有认真看。
结果就是，本地分支虽然叫：
codex/test-code-cleanup
但它实际 tracking 的是：
origin/master
也就是说，它变成了：
codex/test-code-cleanup -> origin/master
这是一个非常危险的状态。
功能分支可以基于 master，但不应该 tracking master。
基于 master 是起点问题。
tracking master 是关系问题。
这两个不是一回事。
问题是怎么被发现的
我后来发现问题，是因为我看到功能分支上的 commit，全部出现在了 origin/master 上。
更严重的是，中间并没有正常的 merge 操作。
也就是说，这些提交不是通过一个清晰的 MR、merge commit 或者合并流程进入 master 的，而是直接出现在了远端 master 的提交历史里。
这时候问题已经不是“有风险”了。
问题已经发生了。
git push 已经发生了。
git rebase 也已经发生了。
并且其他分支已经基于新的 master 做过 rebase 了。
所以这次操作在协作意义上已经不能随便撤销了。不是说 Git 技术上完全没有办法回退，而是现实里已经不能轻易重写这段历史了。
因为一旦强行回滚或者改写 master 历史，就会影响其他已经 rebase 过的分支，后续所有人的提交关系都会被牵连。
所以最后只能接受一个事实：
后续的提交，都只能基于这些节点继续往前走。
这也是这次事情最让我后怕的地方。
万幸的是，这些提交里的代码本身没有问题。
如果这批代码里有明显 bug，或者有不该进 master 的实验代码、临时代码、破坏性代码，那这次就不是一次 Git 事故复盘了，而可能会直接变成一次线上事故。
真正的问题不是 Git，而是我没有握住方向盘
这次问题的根源，不是 Codex “故意做错了什么”，也不是 Git “神秘地合并了代码”。
真正的问题是：
我在使用 Codex 的时候，没有把关键操作的确认权握在自己手里。
Codex 能帮我写代码、改代码、整理测试、补文档，这些都很好。
但涉及这些操作时，我不能完全依赖工具流程：
git worktree add
git branch
git checkout
git pull
git push
git rebase
这些命令不是普通的代码修改。
它们会影响分支关系、提交历史、远端状态，甚至影响整个团队后续的开发基线。
这次我忽略了几个很基础的检查。
比如：
git branch -vv
如果当时我看一眼，就能发现：
codex/test-code-cleanup cd8d7c28 [origin/master] docs: 补充测试维护说明
这里的 [origin/master] 已经很明显了。
它在告诉我：这个功能分支 tracking 错了。
也可以用：
git config --get-regexp '^branch\..*\.merge'
检查本地分支到底绑定到了哪个远端分支。
正确的创建方式应该是：
git worktree add .worktrees/codex/test-code-cleanup \-b codex/test-code-cleanup \--no-track origin/master
或者创建后立刻解除 upstream：
git branch --unset-upstream codex/test-code-cleanup
这条命令不会修改提交，也不会删除分支，只是移除它和 origin/master 的 upstream 关系。
这次给自己的教训
这次事情之后，我要给自己留几条规则。
第一，Codex 可以帮我干活，但 Git 状态必须由我确认。
尤其是让 Codex 创建 worktree、切分支、提交代码、同步远端之前，我必须先看：
git status
git branch -vv
第二，功能分支可以基于 master，但不能 tracking master。
以后只要看到功能分支后面出现：
[origin/master]
就要立刻停下来。
第三，AI 编程不是完全自动驾驶。
我以前容易把 Codex 当成一个“帮我执行任务的人”。
但这次提醒我，它更像是一个很强的副驾驶。
它可以提速，可以帮我处理很多细节，但最后的路线、分支、提交、远端状态，还是要我自己确认。
第四，越是使用 AI，越要有自己的检查清单。
因为 AI 会让我做事变快。
但做事变快以后，如果检查流程没有跟上，错误也会被更快地放大。
这次问题不是“差点出事”。
而是已经出事了。
只是因为提交内容本身没有问题，所以没有继续扩大成线上事故。
以后固定检查
以后每次让 Codex 开一个独立任务前，我都要先确认三件事：
git status
git branch -vv
git remote -v
任务结束后，再确认一次：
git branch -vv
git log --oneline --decorate -5
如果涉及 push、rebase、pull、merge，还要先停一下，确认当前分支和 upstream 关系。
这不是麻烦。
这是我使用 AI 编程工具时必须补上的安全感。
这次真正的教训是：
我在使用 Codex 的时候，不能只看代码有没有改对。
还要看分支有没有站对，远端有没有指对，历史有没有推对。
AI 可以帮我踩油门，但方向盘必须在我手里。