引入
当两个分支修改了同一文件的相近位置，Git 无法替开发者判断应该保留哪一版，就会暂停合并。冲突本身不是异常，真正危险的是不理解当前合并状态就继续执行命令。
正文
识别冲突
git status冲突文件中会出现：
<<<<<<< HEAD
当前分支内容
=======
正在合并的分支内容
>>>>>>> feature/login需要人工编辑文件，保留正确内容，并删除这些冲突标记。不能简单地默认选择一方，因为两边可能都包含必要修改。
完成合并
git add <已解决的文件>如果是变基过程中发生冲突：
放弃当前操作：
处理原则
- 先用
git status确认是 merge 还是 rebase。 - 理解冲突两侧代码的业务意图。
- 手动编辑并删除冲突标记。
- 运行格式检查、单元测试或构建。
- 暂存解决后的文件，再继续合并流程。
解决冲突后，重点验证行为是否正确，而不是只确认 Git 不再显示冲突。必要时找原修改者确认业务逻辑。
引出
减少冲突比熟练解决冲突更便宜：保持分支短生命周期、频繁同步主分支、避免一个提交混合多个功能，并尽量减少无意义的全文件格式化。误操作恢复见 Git撤销与恢复。