在团队协作开发中，Git 是最常用的版本控制工具。然而，当多人同时修改同一文件的相同部分时，合并冲突（Merge Conflict）便不可避免地出现。这不仅会打断开发流程，还可能因处理不当导致代码丢失或逻辑错误。作为开发者，掌握高效、严谨的冲突解决步骤至关重要。本文将通过清晰的清单式教程，帮助你在面对 Git 合并冲突时从容应对，确保代码库的健康与稳定。
识别冲突文件与理解状态
解决冲突的第一步是准确识别哪些文件发生了冲突。当你执行 git pull 或 git merge 命令后，如果终端返回错误信息并提示“CONFLICT”字样，说明存在未解决的冲突。此时，你可以运行 git status 命令查看具体状态。在输出结果中，标记为 “both modified” 的文件即为冲突文件。
值得注意的是，并非所有差异都是冲突。Git 能够自动合并那些修改不同行或不重叠的部分。只有当两个分支对同一文件的同一区域进行了不同修改时，才会产生真正的冲突。因此，仔细检查 git status 的输出，聚焦于被明确标记为冲突的文件，避免在无需处理的文件上浪费时间。这一步骤的核心在于“确认范围”，确保你只处理真正需要人工干预的部分。
解析冲突标记与手动编辑
一旦确定了冲突文件，下一步便是打开这些文件进行内容审查。Git 会在冲突区域插入特殊的标记，通常表现为 <<<<<<< HEAD、======= 和 >>>>>>> branch-name 三段式结构。这些标记将代码分为三个部分：当前分支（HEAD）的代码、目标分支（如 main 或 feature）的代码，以及两者之间的分隔线。
你需要仔细阅读这三部分内容，判断哪一部分是正确的，或者是否需要将两者结合。例如，如果一方添加了新功能 A，另一方优化了旧功能 B，且两者互不干扰，你可能需要保留两者的修改。但如果双方都试图重写同一段核心逻辑，则必须根据业务需求决定保留哪一个版本，或者重新编写新的逻辑以兼容双方意图。在此过程中，务必删除所有的冲突标记符号，确保最终代码符合标准语法规范。这是最耗时也最关键的一步，直接决定了合并后的代码质量。
测试验证与提交完成合并
手动编辑完冲突文件后，切勿立即提交。首先，你需要重新添加这些文件到暂存区，使用命令 git add <filename>。这告诉 Git 你已经解决了该文件的冲突。如果有多个文件发生冲突，需逐一添加。随后，强烈建议运行项目的单元测试或集成测试，以确保合并后的代码逻辑依然正确，没有引入新的 Bug。特别是在重构或大规模修改场景下，自动化测试是防止回归错误的最后一道防线。
确认无误后，即可执行 git commit 完成合并操作。Git 通常会自动生成一个默认的合并提交消息，你也可以根据需要自定义消息，以便后续追溯。最后，再次运行 git status 确认工作区干净，没有任何未提交的更改。至此，合并冲突的处理流程正式结束。通过遵循这套步骤，不仅能高效解决问题，还能培养良好的版本控制习惯，提升团队协作效率。
