在团队协作开发中，使用 Git 进行版本控制已是常态。每当多人同时修改同一文件的不同部分，尤其是临近上线前的冲刺阶段，合并请求（Merge Request）时出现冲突几乎是家常便饭。这时候，光靠平台提示“有冲突”可不够，得动手解决才行。
冲突是怎么产生的？
假设你和同事都在开发新功能，都从主分支拉出了自己的分支。你在分支 A 修改了 config.js 的第 10 行，而同事在分支 B 也改了同一文件的第 10 行，然后你们先后提交合并请求。当第一个请求被合并后，第二个请求就会提示冲突——因为 Git 不知道该保留谁的改动。
如何识别冲突？
在 GitLab 或 GitHub 上发起合并请求时，如果系统检测到无法自动合并的更改，会明确标注“Merge conflict”。点进去通常能看到冲突的文件列表。本地执行 git merge 或 git pull 时，终端也会提示类似“Automatic merge failed; fix conflicts and then commit the result.”
手动解决冲突的基本步骤
先切换到你的功能分支，然后尝试合并目标分支（如 main）：
git checkout feature/login-update
git merge main如果发生冲突，Git 会在相关文件中标记出冲突区域：
<<<<<<< HEAD
const timeout = 5000;
=======
const timeout = 8000;
>>>>>>> main上面那段是当前分支的内容（HEAD），下面是即将合并进来的改动。你需要决定保留哪一部分，或者重新写一个更合适的值。比如最终改成：
const timeout = 6000;然后删除标记符号，保存文件，再执行：
git add config.js
git commit -m "resolve merge conflict in config.js"这样就算处理完了。接着推送更新，合并请求页面上的冲突提示也会消失。
用工具提升效率
面对多个文件冲突，纯手动编辑容易出错。很多人会用 VS Code 内置的合并编辑器，点一下就能选择接受当前、传入或两者都保留。也可以配置外部工具，比如 meld 或 vimdiff，通过命令 git mergetool 启动图形化比对界面，左右拖拽更直观。
预防胜于治疗
经常同步主干代码能大大降低冲突概率。建议每天上班第一件事就是拉取最新 main 分支：
git checkout main
git pull
git checkout your-feature-branch
git merge main越早发现问题，越容易处理。另外，拆分大功能为小模块提交，也能减少单次改动范围，让冲突更集中、更容易理清逻辑。
实际项目中见过有人因为怕冲突干脆不拉最新代码，结果一合并几十个文件红着，修了一整天。与其临时抱佛脚，不如平时勤快点，小步快跑才是正道。