在团队协作开发中，你刚写完一段代码，信心满满地发起合并请求（Merge Request），结果系统弹出一行红字：‘存在冲突，无法自动合并’。这时候别慌，这种情况太常见了，几乎每个开发者都踩过这个坑。
冲突是怎么来的？
简单说，就是你和同事改了同一个文件的同一部分。比如你修改了 login.js 的登录逻辑，同时另一位同事也调整了同一函数的参数处理方式。Git 不知道该保留谁的改动，于是就标记为冲突，需要人工介入。
怎么发现冲突？
通常在 GitLab 或 GitHub 上提交 MR 后，页面会明确提示 ‘Conflicting files’。点进去能看到具体哪些文件冲突，每一处都会用 <<<<<<<、=======、>>>>>>> 这样的标记分隔开你的代码和目标分支的代码。
本地解决冲突更稳妥
比起在线编辑器，我更建议把目标分支拉到本地，再合并自己的分支来处理冲突。步骤很简单：
git checkout main
git pull origin main
git checkout feature/login-update
git merge main一旦出现冲突，Git 会列出未合并的文件。打开这些文件，找到冲突标记，仔细比对逻辑，决定保留哪部分，或者融合两者。改完后执行：
git add .
git commit -m "resolve merge conflict in login.js"
git push origin feature/login-update别忘了验证代码
解决完别急着提交，运行一下项目，确保功能没被搞坏。有时候看似合理的合并，反而引入了隐藏 bug。尤其是接口字段变更这种，前端和后端容易对不上。
工具能帮你省力
VS Code 自带的合并编辑器就很实用，左右对比清晰，一键选择接受当前或传入的更改。如果你用的是 WebStorm，它的图形化合并工具也能高亮差异，拖拖拽拽就能搞定。
预防胜于治疗
经常拉取主干更新，不要让分支长期脱离主线。分支生命周期越长，冲突概率越高。另外，拆小功能点，提小合并请求，不仅审查轻松，冲突也少得多。
合并请求冲突不是问题，关键是怎么快速、安全地解决。养成好习惯，用对工具，你会发现这事儿也没那么烦人。