路科提到Git合并冲突，做过几年开发的人基本都遇到过。尤其多人协作时，你正高高兴兴准备合并分支，结果控制台一堆CONFLICT，心里那个滋味我太懂了。这篇东西不聊虚的，直接说清楚合并冲突的几种主流解决方案，包括纯命令行、IDE可视化操作、工具辅助处理，以及那个很实用的“只解决冲突那段，其他正常合并”的玩法。无论你是刚接触Git的新手，还是被冲突折磨过几次的老兵，都能在这里找到用得上的东西。
先说一个总体结论：合并冲突并不可怕，本质就是Git在告诉你“两边都改了同一块地方，我拿不准该听谁的”。只要把原理理顺，再配合正确的工具和思路，十分钟内基本都能解决。
1. 合并冲突到底怎么来的——先搞懂根源再动手
1.1 冲突的本质不是“代码坏了”，而是“两个提交改了同一处”
很多人第一次遇到冲突时，第一反应是“代码是不是被弄坏了”。这里要先替Git说句话：Git本身非常聪明，大多数合并它都能自动完成。它只在一种情况下会喊你出来裁决——两个分支都对同一个文件的同一段内容做了不同的修改，而且Git无法判断哪一边才是你真正想要的。
比如你在feature/login分支上改了UserService.java的login()方法，你同事在main分支上也改了同一个方法，哪怕你俩改的行不是完全一样，Git只要发现这俩分支从某个共同祖先提交之后，都在同一段代码区域动了手脚，就会标记为冲突。Git不是不会合并，而是不想替你做一个可能错的决定，于是把决定权交到你手上。
这里有个关键点：冲突往往不代表“两人写错了”，而是代表“同一块代码被并行修改过”。这其实是团队协作的正常产物，和代码质量无关，所以千万别一看到冲突就着急。
1.2 冲突发生的常见场景和规律
根据我这几年的观察，冲突多集中在这些地方：
- 多人同时修改同一个文件，尤其是那些“公共类”、“配置类”、“工具类”；
- 分支长期没同步主干，导致合并时差异范围太大；
- 格式化工具不统一，比如有人用4空格缩进、有人用Tab，全文件diff全是冲突；
- 合并
main到自己的功能分支时，中间隔了太多新提交。
不过大多数冲突坑其实是可控的。后面我会专门聊怎么减少冲突的频次。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 解决合并冲突的主流方案对比——选对路子能省一半时间
2.1 高频方案速览表
在展开讲细节之前，先把常见的几种方案放一张表里，方便你对着实际情况选。
| 方案 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 命令行手动编辑 | 任意场景，尤其是冲突少时 | 最通用，不依赖IDE，完全可控 | 冲突格式眼花，新手容易手误 |
| IDE可视化合并（IntelliJ IDEA等） | 日常开发，冲突较复杂 | 界面直观，可左右对照，能精准选段 | 依赖IDE，换工具后有学习成本 |
| 合并工具（Beyond Compare、Meld等） | 冲突量大、文件大时 | 对比能力强，高亮清楚 | 需要额外安装和配置 |
git checkout --ours/--theirs |
明确要以某一侧为准 | 一行命令快速解决 | 整文件覆盖，无法精准到段 |
git merge --abort |
局面混乱，想重新来过 | 一键还原到合并前 | 会丢弃这次合并且之前改动的暂存内容需注意 |
| rebase替代merge | 想减少合并提交和部分冲突 | 历史线干净 | 冲突可能连续出现，处理不好有风险 |
2.2 选方案前先判断冲突规模
我在实际处理冲突时，第一步不