浏览 AI 知识库
Git 合并冲突怎么解决：分清两边意图并完成回归验证
解决 Git 冲突不是把两边文字都留下。先弄清两项改动分别想保护什么业务行为，再合并代码并跑针对性的回归测试。
“保留双方”能消掉冲突标记，却不一定保住两边逻辑
合并冲突的一边把 `status` 改成枚举，另一边新增了 `pending_review` 分支。简单选择“保留双方”后代码编译，但旧字符串仍绕过新校验。
- 每个冲突块的双方意图已记录
- 合并结果不是简单拼接
- 双方测试与跨分支回归已运行
Git 合并冲突怎么解决，先从“同一逻辑被两边修改”这一类现象查起
同一逻辑被两边修改
- 原因
- 两个变更可能解决不同问题或建立不同不变量。
- 怎么改
- 分别读取提交、测试和调用方，列两边必须保留的行为，再写兼容实现。
一边重命名，一边继续编辑旧文件
- 原因
- 文件路径变化掩盖了内容修改。
- 怎么改
- 追踪历史和符号，先把内容改动迁到新位置，再删除旧文件。
依赖或锁文件冲突
- 原因
- 手工拼接锁文件可能产生不存在的依赖图。
- 怎么改
- 先决定清单文件的正确依赖，再用项目包管理器重新生成并审查差异。
生成物冲突
- 原因
- 源数据或生成器已经变化，直接合并产物会过期。
- 怎么改
- 确认权威源，解决源文件后运行仓库生成命令，不手改生成结果。
复测前，固定原始现象、环境和目标
| 需要确认 | 本例内容 |
|---|---|
| 现有材料 | 冲突文件为订单状态模型与处理器；主分支引入枚举，功能分支新增审核状态；两边提交说明和测试可读。 |
| 不能越过的边界 | 先理解两边业务意图，再写第三个整合版本；不只删除冲突标记；合并后跑双方相关测试。 |
| 要交付的结果 | 冲突决策记录与回归结果 |
ours/theirs 都改订单状态时，先还原两边不变量
| 冲突 | 两边意图 | 合并决定 | 回归 |
|---|---|---|---|
| 状态枚举 | A 加 cancelled，B 加 refunded | 保留两种状态并更新映射 | 状态转换表和接口测试 |
| 锁文件 | 两边升级不同依赖 | 先定 package.json，再重新生成锁文件 | 安装和构建 |
| 生成物 | 源数据与生成器都变了 | 解决源后重新构建 | 生成物 diff 可追溯 |
冲突内容和分支为演示；真实决定回到提交、调用方和测试。
Git 合并冲突怎么解决：按原条件复测的结果
原始现象
文本冲突已消失，但新状态仍以旧字符串比较，审核订单走到默认分支。
冲突决策记录与回归结果
整合版本把 `pending_review` 加入枚举并更新转换、处理器和迁移；决策记录说明保留两边意图。主分支枚举测试、功能分支审核测试和新增兼容测试全部通过。