冲突解决与变更管理

多人协作，难免冲突

多个人（或 AI）同时改代码，Git 合并时就会冒出冲突——两个人改了同一个地方。冲突不可怕，处理不当才可怕。这一节讲冲突解决与变更管理，特别是和 Codex 协作时怎么处理。

---

冲突是怎么来的

你和同事、或你和 Codex，同时改了同一文件的同一区域，合并时就冲突了：

你改了 第 20 行，Codex 也改了第 20 行
→ Git 不知道听谁的，冲突了

本质：同一处有两个改法，需要人裁决。 在 file-lib 里，最典型的就是 index.js（汇总导出所有模块）和 package.json（注册依赖和 bin），因为这两个文件是「公共交汇点」，大家都在上面加东西。

main:        index.js  导出 [string, io, path]
feature/a:   index.js  导出 [string, io, path, date]   ← 你加了 date
feature/b:   index.js  导出 [string, io, path, cli]    ← 同事加了 cli
→ 合并时，Git 在 index.js 的第 17 行附近冲突

两个分支都在「导出列表」这个公共区域动了手，Git 不知道该怎么拼。

---

冲突别怕，按步骤解决

1. 先看 git status，知道哪些文件冲突了
2. 打开冲突文件，看冲突标记（<<<<<<< / ======= / >>>>>>>）
3. 分析两边的改动，决定保留哪个、怎么合并
4. 手动修正，删掉冲突标记
5. 重新 add + commit，完成解决

关键：你要读两边的改动，做出正确的合并，不是随便选一边。冲突标记长这样：

<<<<<<< HEAD
  module.exports = { string, io, path, date }
=======
  module.exports = { string, io, path, cli }
>>>>>>> feature/b

上面是 HEAD（你这边），下面是另一个分支。file-lib 的正确合并是两者都留：

  module.exports = { string, io, path, date, cli }

删掉标记，保留两边都要的东西。

---

让 Codex 帮你分析冲突

冲突文件读起来费劲，可以让 Codex 帮你看：

git 冲突了，帮我分析这两个分支在 src/auth.ts 的改动：
- 我这边改了什么
- 分支改了什么
- 应该怎么合并
给出建议，我确认后手动处理。

AI 分析、人裁决——Codex 帮你理解，但你做最终合并决定。对 file-lib 的 index.js 冲突：

index.js 冲突了。帮我分析：
- HEAD（我的分支）加了什么导出
- 另一个分支加了什么导出
- 两边的改动能不能共存，应该怎么合并成一行
给出建议，我自己来改，你只分析。

注意最后那句「我自己来改，你只分析」——冲突的最终合并是人的责任，让 Codex 动手容易「选一边」而不是「正确合并」。

---

变更管理：让改动可追溯、可回滚

和 Codex 协作，变更管理尤其重要：

• 小步提交：改一点、提交一点，别攒一堆难回滚
• 信息清楚：每次提交写明「改了什么、为什么」
• 可回退：出问题能 git log 找到、能回滚到上一个稳定点

变更管理 = 让 AI 的改动「有据可查、随时能退」。 对 file-lib 来说，小步提交特别关键——Codex 一次会话可能改了很多，如果你让它「攒一起再提交」，出问题时 git log 里全是混在一起的大改动，想单独回滚某个模块都不可能。宁可多几个小提交，也别一个大提交。

---

一个完整处理示例

你：git merge，报冲突在 src/auth.ts
你：让 Codex 分析两个分支的改动
Codex：你的分支加了邮箱校验，另一分支改了错误提示，可共存
你：手动合并两处，删掉冲突标记
你：git add src/auth.ts && git commit
你：跑测试确认没破坏

冲突解决 + 验证，一次搞定。对应到 file-lib：

git merge feature/cli            # 报冲突在 index.js
# 让 Codex 分析：HEAD 加了 date，feature/cli 加了 cli，可共存
# 手动合并 index.js，删掉 <<<<<<< 标记
git add index.js
git commit -m "merge: 合并 cli 功能，同时保留 date 导出"
npm test                          # 跑测试确认没破坏其他模块

手动改完一定要跑测试，确认「合并后的 index.js 所有导出都能正常 require」。

---

常见坑：让 Codex「自己解决冲突」，它选了一边

冲突时你把整件事丢给 Codex：「帮我解决一下冲突」。结果它为了快点完事，直接把冲突标记里的一边删掉，另一边的功能就无声无息地丢了。等上线才发现某个模块没了，回滚又要重来。

避坑办法：冲突解决不能让 AI 全权代理，你至少要审它合并的结果。更稳的做法是让 Codex 只分析、你来改：

你只负责分析，我来手动合并。给出：
- HEAD 保留了什么、丢了什么
- 分支保留了什么、丢了什么
- 正确合并应该保留哪些内容
不要替我改文件。

如果你还是让它动手，那改完必须复查合并结果，重点确认「两边的功能是不是都保留了」。冲突是人的裁决，不是 AI 的赌注。

---

小结

1. 冲突 = 同一处两个改法，需要人裁决
2. 解决五步：看状态 → 看标记 → 分析 → 修正 → 重提交
3. 让 Codex 分析，人做最终合并决定
4. 变更管理：小步提交、信息清楚、可回滚

下一节，讲团队 Git 规范落地。