使用 Codex 在独立分支里修改代码时，最常见的问题之一就是：

代码本身没问题，但一合并就出现 Git 冲突。

常见情况包括：

• Codex改了一个文件，主分支同时也被其他人修改；

• 多个Agent同时处理不同任务，却碰到了同一段代码；

• git merge 或 git rebase 后出现冲突；

• 文件里突然出现 <<<<<<<、=======、>>>>>>>；

• 不知道到底该保留哪一边。

这类问题并不代表 Codex 修改失败。

本质上是：

Git无法自动判断两份修改应该怎么合并。

---

一、为什么用了Codex以后更容易遇到冲突？

以前一个开发者可能一次只维护一个分支。

现在使用 Coding Agent 后，很容易变成：

main
├─ feature-a
├─ fix-bug
├─ agent-task-1
└─ agent-task-2

如果这些分支都修改：

src/user/service.ts

甚至修改了同一段代码，Git就可能无法自动合并。

所以Agent并行任务越多，冲突概率通常也会增加。

---

二、先不要急着让Codex重新生成代码

看到冲突以后，很多人的第一反应是：

再让Codex把这个文件改一遍。

这反而容易让Diff变得更复杂。

第一步应该先执行：

git status

Git会直接告诉你哪些文件存在冲突。

例如：

both modified: src/user/service.ts

先确定冲突范围，再处理具体文件。

---

三、这三个符号分别是什么意思？

打开冲突文件后，通常会看到：

<<<<<<< HEAD
当前分支的代码
=======
另一个分支的代码
>>>>>>> feature/login

可以理解成：

<<<<<<< HEAD
你当前这一边

=======
两边分隔线

>>>>>>> feature/login
准备合并进来的另一边

真正要做的不是简单删除符号。

而是判断：

两边修改的业务意图分别是什么。

---

四、不要直接“全部接受当前”或“全部接受对方”

编辑器通常会提供：

• Accept Current；

• Accept Incoming；

• Accept Both。

这些按钮很方便，但不能机械使用。

例如：

当前分支增加了：

权限检查

另一分支增加了：

缓存清理

如果直接选择其中一边，就可能把另一项功能删掉。

正确结果可能应该同时保留：

权限检查
+
缓存清理

所以解决冲突最重要的是：

合并逻辑，而不是合并文本。

---

五、可以让Codex先解释两边修改意图

如果冲突代码比较复杂，可以把冲突交给 Codex 分析，但不要直接让它覆盖文件。

例如要求：

请先分析这个Git冲突。

说明：
1. HEAD这边修改了什么；
2. Incoming这边修改了什么；
3. 两边是否可以同时保留；
4. 是否存在逻辑冲突；
5. 给出建议合并结果，但先不要修改文件。

这样可以先判断方案。

确认以后再进行实际修改。

---

六、公共文件冲突要特别谨慎

有些文件发生冲突，风险明显更高。

例如：

api/client.ts
auth.ts
router.ts
package.json
schema.prisma

这些文件往往被大量模块共享。

即使冲突只有十几行，也可能影响很多功能。

所以不能只看：

冲突行数多不多。

还应该看：

这个文件影响范围有多大。

公共模块最好人工再检查一次。

---

七、解决冲突后一定要重新测试

冲突处理完成，只说明：

Git已经可以继续合并。

不代表业务逻辑一定正确。

解决后先检查：

git status

确认没有未解决冲突。

然后运行：

git diff

看最终代码是否符合预期。

再执行项目测试，例如：

npm test

或者项目自己的测试命令。

尤其需要确认：

• 两边功能是否都保留；

• 有没有重复代码；

• 有没有遗漏导入；

• 类型检查是否正常。

---

八、处理完后再完成合并

如果确认冲突已经处理完成，可以根据当前流程执行：

git add .

然后继续：

git commit

如果使用的是 rebase，可能需要：

git rebase --continue

不同操作对应的后续命令不同。

所以在执行之前，最好先确认自己当前是在：

merge流程还是rebase流程。

---

九、如何减少Agent之间的Git冲突？

最有效的方法不是“更会解决冲突”。

而是提前减少冲突。

可以让不同Agent尽量负责不同模块。

例如：

Agent A → 前端页面
Agent B → API
Agent C → 测试

而不是三个Agent同时修改同一个核心文件。

任务开始前也可以要求：

先说明准备修改哪些文件，如果涉及公共模块先暂停确认。

这样可以提前发现任务重叠。

---

十、任务越小，冲突通常越容易处理

例如：

重构整个用户模块。

可能一次改十几个文件。

如果拆成：

任务1：调整登录校验
任务2：补充测试
任务3：修改缓存逻辑

每个分支的Diff更小。

即使发生冲突，也更容易判断：

哪一部分应该保留。

这也是Agent并行开发时很重要的一条原则。

---

最后

Codex修改代码后出现Git冲突，不代表代码一定有问题。

真正发生的是：

两个分支对同一部分代码做了不同修改，Git无法自动判断最终结果。

处理时建议按照：

git status
↓
确认冲突文件
↓
理解两边修改意图
↓
手动合并逻辑
↓
重新检查Diff
↓
运行测试

这个顺序处理。

最需要避免的是：

看到冲突就直接全部接受某一边。

因为Git冲突真正需要解决的不是文本差异，而是：

两份代码背后的业务逻辑如何同时成立。

---

持续更新 Codex、大模型开发与 AI 编程实战内容，更多技术内容和稳定订阅渠道欢迎搜索关注「仙逆GPT」。