合并冲突的完整处理流程：从识别到解决的实操步骤
上个月团队做电商平台迭代时，两个同事同时改了购物车逻辑——小张加了”优惠券叠加计算”，小李优化了”商品数量限制”，结果合并时整个cart.js文件都飘红了。当时小李没细看就删了冲突标记，差点把小张的优惠券代码全删了，还好提交前被代码评审拦了下来。这事儿让我意识到，处理冲突真不是”删标记”这么简单，得按步骤来才不会出问题。
第一步：先搞懂”冲突从哪来”
你可能会问，为什么好好的代码会冲突？其实就像两个人同时改一份Word文档——如果你们改的是不同段落，Git能自动合并；但如果改了同一段落甚至同一行，Git就分不清该留谁的代码，这就是冲突。常见原因有三种：同一文件同一行被修改（最常见，比如两个同事都改了登录按钮的颜色值）、文件被一方删除另一方修改（比如前端删了旧组件，后端还在调用）、二进制文件冲突（如图片、Excel，Git无法自动合并）。
第二步：识别冲突的3个信号
冲突发生时Git会明确告诉你，别慌着点”解决冲突”按钮。你可以通过三种方式发现：一是GitLab的合并请求页面会显示”无法自动合并”，并列出冲突文件；二是命令行执行git merge [分支名]时，会提示”Automatic merge failed; fix conflicts and then commit the result”；三是用VS Code这类编辑器打开项目，冲突文件会标红，鼠标移上去能看到”冲突”提示。
第三步：按”拉取-查看-编辑-验证”四步解决
这是最关键的部分，我带实习生时都会让他们背这个流程：
git checkout feature/cart），执行git pull origin develop拉取目标分支的最新代码——这步千万别省！上个月小王就是没拉最新代码，合并时把同事刚提交的支付接口改覆盖了，白干两小时。 git status命令能看到标红的”both modified”文件，或者直接在VS Code左侧文件树找带红色感叹号的文件。双击打开后，你会看到Git用特殊标记分隔的代码块：<<<<<<< HEAD到=======是你当前分支的代码，=======到>>>>>>> [分支名]是待合并分支的代码。 discount = coupon1 + coupon2，小李的是if (quantity > 10) discount = 0，其实两者不矛盾，正确做法是把小李的判断逻辑包在小张的计算外面，而不是删一个留一个。改完后一定要删掉所有冲突标记（<<<<<<>>>>>>），不然Git会认为冲突没解决。 git add [冲突文件名]告诉Git”这个文件解决好了”，然后git commit -m "解决购物车逻辑冲突：合并优惠券与数量限制"，最后git push推送到远程分支。 这里有个小技巧：如果冲突文件太多，用命令行改不过来，可以用GitLab的网页端解决——在合并请求页面点击”解决冲突”按钮，会打开在线编辑器，左侧是你的代码，右侧是待合并分支代码，中间是合并结果，改完直接提交，适合新手操作。但要注意，网页端看不到完整项目上下文，复杂冲突还是 在本地用编辑器改，改完记得跑一遍npm run test，确保功能没崩。
10个高频踩坑点与冲突预防策略
光会解决还不够，更重要的是少踩坑。我整理了过去两年团队遇到的10个典型案例，你可以对照看看自己有没有中招：
这些”坑”你可能天天踩
git push -f，这相当于告诉Git”无视远程分支，用我的本地分支覆盖”，如果远程有同事刚提交的代码，直接就被你删了！正确做法是git pull rebase先把远程代码拉下来，解决冲突后再push。 3个让冲突”少发生”的预防策略
最好的解决是不发生冲突。分享三个团队实测有效的方法：
feature/payment-zhangsan、bugfix/login-lisi，谁改了什么一目了然，改同一文件前先在群里说一声。 GitLab官方文档里有句话我特别认同：”冲突不是敌人，而是协作的信号”（https://docs.gitlab.com/ee/user/project/merge_requests/resolve_conflicts.htmlnofollow）。只要按流程处理、提前预防，冲突反而能帮团队发现协作中的问题。
最后送你一个”冲突处理 checklist”，贴在工位上随时看：
✅ 合并前先git pull拉最新代码
✅ 冲突文件先看标记上下的代码逻辑
✅ 改完删光所有冲突标记
✅ 提交前跑测试用例
✅ 复杂冲突及时和修改者沟通
你平时处理冲突时遇到过什么奇葩情况？或者有什么独家小技巧？欢迎在评论区分享，咱们一起把”合并冲突”变成”协作加分项”！
你有没有试过改冲突改到一半，越改越乱，突然发现自己把别人的关键代码删了？或者冲突标记删到一半，看着屏幕上的代码完全不知道哪部分该留？别慌，这种时候撤销操作比硬着头皮改下去更靠谱。我去年带的一个实习生就遇到过——他合并分支时冲突文件有200多行，改到第50行突然发现自己把后端的接口调用代码误删了，当时脸都白了，我让他赶紧在命令行敲git merge abort，按回车之后，文件瞬间回到了冲突前的样子，他当场松了口气说“像做了场噩梦”。
这里得说清楚，不同情况要用不同的撤销命令。如果你是用git merge [分支名]命令合并时遇到的冲突，就用git merge abort，这个命令会终止当前的合并过程，把代码恢复到合并前的状态；要是你用的是git rebase [分支名]（变基合并），那就得用git rebase abort，道理一样，都是让代码回到冲突发生前。这两个命令就像“后悔药”，只要你还没执行git commit提交冲突解决方案，随时都能吃，而且不会留下任何“后遗症”。
那要是手快，已经提交了冲突解决方案，但还没推送到GitLab远程仓库，还能救吗？也能！不过这时候就得用git reset hard HEAD^了。HEAD^其实就是“上一个提交”的意思，hard是强制回退的参数，执行完之后，你本地的代码就会回到上一次提交的状态，刚提交的那个冲突解决方案会被直接删掉。但这里有个大前提：一定是还没推送到远程！要是已经git push了，就千万别用这个命令，不然远程仓库的代码你回退不了，反而会制造新的冲突。我同事老王就吃过这亏，他提交后发现错了，没看是否推送就reset，结果远程仓库还留着错误的提交，最后只能再改一遍重新提交，白折腾半小时。
不管用哪种撤销方式，有个小习惯能帮你减少损失——改冲突前先把当前代码复制一份到本地文件夹，或者用git stash暂存一下。比如你可以先执行git stash save "冲突解决前备份"，把当前修改暂存起来，等撤销操作完成后，再用git stash pop把备份恢复，这样就算撤销出问题，至少还有备份能找回代码。我自己处理复杂冲突时，这个习惯救过我好几次，毕竟代码这东西，多一层保障总没错。
冲突解决到一半发现操作错了，能撤销吗？
可以撤销。如果还没提交冲突解决方案，命令行中执行 git merge abort（合并过程中）或 git rebase abort（变基过程中），就能回到冲突前的状态。如果已经提交但还没推送到远程，可执行 git reset hard HEAD^ 回退到上一次提交（注意：此操作会删除当前提交的内容， 先备份关键代码）。
多人协作时，怎样提前避免合并冲突？
核心是“减少冲突发生的机会”。 ① 每天下班前将目标分支（如develop）的最新代码合并到自己分支（git pull origin develop），小步合并比攒一堆代码再合并更安全；② 按模块拆分分支，比如“feature/payment”“feature/cart”，避免多人同时改同一模块；③ 改文件前在团队群同步，确认是否有人正在修改同一文件，减少“撞车”概率。
冲突文件里的<<<<<<>>>>>>后面的分支名分别代表什么？
<<<<<<<< HEAD到=======之间的代码是“你当前所在分支的修改”（比如你正在合并的feature分支）；=======到>>>>>> [分支名]之间是“待合并分支的修改”（比如develop分支）。举个例子，如果你在feature/cart分支合并develop，>>>>>> develop后面就是develop分支的代码，这样能清晰区分哪部分是自己的，哪部分是别人的。
冲突解决后必须测试吗？只改了几行代码也需要吗？
必须测试，哪怕只改了一行。文章中提到的“解决后不测试”是高频踩坑点——比如冲突时误删了隐藏的分号，表面看代码正常，运行时却会报错。 解决冲突后至少做两件事：① 本地跑一遍项目（如npm run dev），确认修改功能正常；② 执行单元测试（npm run test），避免冲突修改影响其他模块。
二进制文件（如图片、Excel）冲突怎么处理？
Git无法自动合并二进制文件，需手动处理。如果是图片冲突， 保留最新修改的版本（比如同事刚更新的设计图），直接用新文件覆盖冲突文件；如果是Excel这类有数据的文件，用办公软件打开两个版本，手动对比内容后合并到一个文件，再替换冲突文件。处理后执行 git add [文件名] 标记为已解决，提交时备注“解决[文件名]二进制文件冲突，保留最新版本”。
