当前位置：首页 > news >正文

Codex多分支开发为什么越来越容易冲突？用Git工作流减少重复合并

news 2026/8/7 21:05:05

使用 Codex 参与项目开发后，一个很常见的变化是：代码修改速度明显变快，但 Git 冲突也可能随之增加。

尤其是同时让 Codex 处理多个任务时，经常出现：

两个分支同时修改同一个文件；
一个任务重构代码，另一个任务还在旧结构上开发；
功能已经完成，却因为冲突无法直接合并；
自动解决冲突后代码能编译，业务逻辑却被覆盖；
一个分支修改了公共类型，其他任务全部需要重新适配；
Codex 为了解决冲突，大范围重写文件；
多个提交混在一起，已经无法判断哪部分代码属于哪个需求。

这些问题并不是 Git 本身难用，而是 AI 让代码修改速度提高以后，原来的分支管理方式开始跟不上开发节奏。

一、为什么使用Codex后Git冲突更容易增加？

传统开发中，一个功能可能需要半天甚至一天。

使用 Codex 后，开发者可能同时推进：

feature/login feature/user-list fix/request-timeout refactor/user-store

如果这些任务都修改：

src/store/user.ts

那么每个分支单独测试都可能正常，但最终合并时一定会出现竞争。

真正的问题不是“有多个分支”，而是：

多个任务的修改边界发生了重叠。

因此，减少冲突的第一步，不是研究更复杂的合并命令，而是控制不同任务修改哪些文件。

二、任务开始前先检查修改范围

让 Codex 执行任务前，可以先要求：

请先不要修改代码。 当前任务： 修复用户登录状态刷新异常。 先输出： 1. 预计修改哪些文件； 2. 是否会修改公共类型； 3. 是否会调整公共工具； 4. 是否可能影响正在进行的其他任务； 5. 哪些文件属于本轮必要修改。

如果两个任务都计划修改同一个核心文件，可以考虑：

调整执行顺序；
先完成一个再开始另一个；
将公共修改单独拆成前置任务；
重新设计模块边界。

比起最后解决几十处冲突，提前发现文件重叠成本更低。

三、一个分支只解决一个明确问题

不推荐这样的分支：

feature/update-project

里面同时包含：

登录修复；
页面样式修改；
类型重构；
依赖升级；
测试调整。

这种分支一旦发生冲突，很难判断应该保留哪部分。

更适合 Codex 的方式是：

fix/login-refresh fix/token-expire feature/user-filter refactor/request-client

每个分支目标明确。

对应的 Git Diff 越小，Codex 和人工开发者都越容易理解。

四、小提交比“大完成后再提交”更安全

一个功能可能包含三个阶段：

第一步：增加测试复现Bug 第二步：修改业务逻辑 第三步：补充异常处理

可以分别提交：

git commit -m "test: reproduce login refresh issue" git commit -m "fix: restore user session after refresh" git commit -m "test: cover expired token case"

这种方式有几个明显优势：

冲突可以定位到具体阶段；
某个修改不需要时可以单独撤销；
Cherry-pick 更方便；
Code Review 更容易；
Codex 后续继续任务时能够快速了解历史。

如果几十个文件全部堆在一个提交里，冲突解决难度会明显增加。

五、什么时候适合使用Rebase？

假设：

main ↓ A - B - C feature ↓ D - E

开发期间 main 又增加了新的提交。

为了让 feature 基于最新代码继续开发，可以使用：

git fetch git rebase origin/main

Rebase 会把当前分支的提交重新应用到最新 main 上。

优势是历史更线性：

A - B - C - D - E

但需要注意：

已经多人共同使用的公共分支，不要随意 Rebase 后强制推送。

Rebase 更适合个人功能分支。

让 Codex 协助解决 Rebase 冲突时，也不要直接让它“全部自动解决”，而应该逐个检查文件。

六、冲突解决时不要只选择ours或theirs

Git 冲突通常会出现：

<<<<<<< HEAD 当前分支代码 ======= 另一分支代码 >>>>>>> feature

很多人会简单选择：

Accept Current

或者：

Accept Incoming

但两边代码可能都包含有效修改。

例如：

当前分支增加：

if (!token) { return logout(); }

另一个分支增加：

if (isExpired(token)) { return refreshToken(); }

真正正确的结果可能是同时保留两个逻辑，而不是二选一。

可以让 Codex 帮助分析：

这是一次Git冲突。 请分别说明： 1. 当前分支修改目的； 2. 目标分支修改目的； 3. 两段代码是否可以同时保留； 4. 合并后有哪些边界场景； 5. 给出最小合并方案。 不要直接覆盖任意一侧代码。

七、Cherry-pick适合提取独立修改

有时候一个大型分支中只有某个修复需要提前进入 main。

例如：

feature/order-refactor 提交A：重构订单类型 提交B：修复空值Bug 提交C：调整页面结构

现在只需要修复 Bug，可以执行：

git cherry-pick <提交B>

前提是提交B足够独立。

这也是为什么前面强调“小提交”。

提交越聚焦，后续复用和迁移越容易。

八、公共文件修改要单独管理

最容易产生冲突的通常是：

package.json；
锁文件；
公共类型；
路由文件；
全局状态；
API 请求封装；
公共配置。

如果多个任务都要修改这些文件，可以将公共变化先放到独立分支：

refactor/user-types

合并后，其他任务统一基于最新 main 继续。

不要让三个 Codex 任务分别定义三个版本的User类型，最后再尝试人工拼接。

九、不要让Codex为了消除冲突顺便重构

解决冲突时，目标应该非常明确：

恢复两个分支原本都需要的业务行为。

不适合在这个阶段做：

全文件格式化；
函数重命名；
目录移动；
类型重构；
新增依赖；
大规模代码抽取。

否则冲突修复会变成一次新的重构任务。

建议给 Codex 明确规则：

当前只处理Git冲突。 要求： - 不重构无关代码； - 不改变函数公共接口； - 不新增依赖； - 不修改冲突文件之外的内容； - 保留两边原有业务意图； - 合并后运行相关测试。

十、合并完成后必须重新测试

“Git 冲突已经消失”只代表文本层面的冲突解决了。

并不意味着逻辑正确。

至少执行：

npm run lint npm run type-check npm run test npm run build

还要重点检查：

两个分支新增的测试是否都通过；
公共类型是否仍然兼容；
是否出现重复逻辑；
是否漏掉某一边的异常处理；
合并后依赖是否正常；
是否产生新的循环引用。

对于关键功能，可以让 Codex 输出一份合并验证报告。

十一、用AGENTS.md限制并行任务

可以加入：

# Git与并行开发规则 - 一个任务只解决一个明确问题 - 修改前必须列出预计文件范围 - 不进行与任务无关的全局格式化 - 公共类型修改必须单独说明 - 不允许自动覆盖Git冲突任意一侧 - 冲突解决后必须运行完整相关测试 - 一个提交只包含一个逻辑目的 - 已共享分支禁止随意重写历史 - Cherry-pick前确认提交是否独立

这样，Codex 在多分支工作中会更容易保持边界。