Git代码冲突解决：保留被合并分支版本的完整指南

1. Git代码冲突的本质与场景还原

当我们在团队协作开发时，经常会遇到这样的场景：你正在feature-A分支开发新功能，同事同时在feature-B分支修改了同一个文件的相同位置。当你尝试将feature-B合并到自己的分支时，Git会立即抛出冲突警告。这种冲突不是Bug，而是版本控制系统在尽职尽责地提醒你："这里有两处修改，我无法自动判断该保留哪个版本。"

冲突的产生通常伴随着这样的提示：

CONFLICT (content): Merge conflict in [文件名] Automatic merge failed; fix conflicts and then commit the result.

2. 为什么需要保留被合并分支的代码？

2.1 典型业务场景分析

假设你正在开发一个支付功能（feature-pay），而同事在用户中心分支（feature-user）修改了用户余额的校验逻辑。当需要合并feature-user时，你明确知道：

1. 同事的校验逻辑已经通过测试验证
2. 你的分支中相关代码还是半成品
3. 业务上必须采用新的校验规则

这时就需要完全采用被合并分支（feature-user）的代码，放弃当前分支的修改。

2.2 技术决策依据

保留被合并分支代码的典型情况包括：

• 被合并分支包含热修复（hotfix）
• 当前分支代码已过时或被废弃
• 被合并分支经过更严格的测试验证
• 架构调整导致当前分支代码不兼容

3. 完整冲突解决流程（保留被合并分支版本）

3.1 识别冲突文件

运行git status查看冲突文件列表，冲突文件会显示为"both modified"状态。使用IDE或编辑器打开这些文件，会看到典型的冲突标记：

<<<<<<< HEAD 当前分支的代码 ======= 被合并分支的代码 >>>>>>> feature-user

3.2 使用被合并分支版本

手动编辑冲突文件，完全删除当前分支的代码块（包括<<<<<<< HEAD和=======行），只保留被合并分支的代码（>>>>>>> feature-user行及其内容）。

或者更高效的做法是使用Git命令：

git checkout --theirs [冲突文件] # 完全采用被合并分支版本 git add [冲突文件] # 标记为已解决

3.3 验证与提交

完成所有冲突文件处理后：

git commit # 会弹出合并提交的默认消息

建议在提交消息中注明冲突解决方式，例如：

Merge branch 'feature-user' into feature-pay Resolve conflicts by accepting all changes from feature-user

4. 高级技巧与避坑指南

4.1 使用图形化工具

对于复杂冲突，推荐使用可视化工具：

• VS Code内置的Git冲突解决器
• GitKraken等专业Git客户端
• IntelliJ IDEA的合并工具

这些工具可以并排显示两个版本的差异，支持点击选择保留哪个版本。

4.2 批量处理多个文件

当需要批量接受被合并分支的所有修改时：

git merge -X theirs feature-user

注意：这会无条件接受被合并分支的所有冲突解决方案，需谨慎使用。

4.3 撤销错误的冲突解决

如果发现冲突解决有误，可以重置合并状态：

git merge --abort # 中止当前合并

或回退到合并前状态：

git reset --hard ORIG_HEAD

5. 团队协作最佳实践

5.1 预防冲突的策略

• 频繁地从主分支拉取更新（每天至少一次）
• 保持小颗粒度的提交（每个提交只解决一个明确的问题）
• 团队成员间及时沟通重大架构修改
• 使用git pull --rebase代替直接pull

5.2 代码审查要点

当审查包含冲突解决的合并请求时，需要特别检查：

1. 冲突解决方式是否符合业务需求
2. 是否意外删除了必要的代码
3. 合并后的代码是否通过所有测试案例
4. 提交消息是否清晰记录了冲突解决决策

6. 常见问题排查

6.1 为什么checkout --theirs不生效？

可能原因：

• 处于rebase过程而非merge过程（此时应使用git rebase --continue）
• 文件未真正产生冲突（先确认git status显示冲突）
• 文件已被手动修改（需要先git reset文件）

6.2 合并后编译错误怎么办？

典型处理流程：

1. 立即回退到合并前状态：git reset --hard ORIG_HEAD
2. 重新合并，但保留当前分支版本：git merge -X ours
3. 逐步手动合并关键修改
4. 确保本地测试通过后再提交

6.3 如何避免下次相同冲突？

• 在团队约定代码组织结构
• 使用Git钩子自动检查常见冲突模式
• 对频繁冲突的模块进行架构重构
• 建立更细粒度的功能分支策略

在实际项目中，我通常会为长期存在的功能分支创建专门的同步计划，每周至少两次与主分支同步。对于核心模块的修改，会提前在团队群组中公告，让相关开发人员预知可能的冲突点。记住，好的Git策略不是避免冲突，而是让冲突尽早且可控地暴露出来。