Git合并冲突处理：删掉标记之前，先确定两边代码的意图

合并冲突不是简单保留左边或右边。本文介绍冲突文件检查、语义合并和提交前验证，降低误删有效改动的风险。

两个人同时改了同一段代码，Git 无法自动决定保留哪一种实现，就会留下合并冲突。冲突标记只是提示范围，删除标记并不代表业务逻辑已经正确。

先读两边的改动

查看拉取请求说明、相关提交与冲突上下文，确认一边在修什么，另一边新增了什么。保留整个文件的某一版本，可能顺手删掉另一项功能。配置文件、依赖锁文件和代码文件也不能用完全相同的处理方式。

按文件完成合并

在有冲突的区域组合出最终逻辑，移除冲突标记，再查看差异。网页编辑器适合简单的逐行冲突，复杂冲突应在本地用开发工具处理。注意在 GitHub 上解决冲突会把基线分支合入当前提案分支，不能理解为只改几行文本。

检查语义是否仍成立

运行受影响模块检查，尤其关注变量改名、接口参数、数据库字段和错误处理。之后确认 git status 中没有未解决项，再完成合并提交。界面变绿只能说明某些规则通过，不保证所有业务场景正确。

如果冲突太大，先保存当前工作并与协作者确认方案，避免强制推送覆盖他人历史。团队可通过缩小提交、及时同步和减少无关格式化，降低下一次冲突的范围。

参考资料

资料核对：2026年10月27日。本文为文档综合与操作建议，未宣称完成本站实测。

GitHub 解决合并冲突

Git cherry-pick 手册