2. 冲突到底是怎么来的

2.1 冲突不是错误，而是一道保护机制

先说一个可能颠覆很多人认知的观点：Git 冲突并不是“坏事”，更不是“代码被弄坏了”。我见过不少新人，一看到 "CONFLICT" 字样就慌，以为整个仓库要重来，其实完全不是这样。冲突恰恰说明 Git 在执行一次“负责任的合并”——它发现两个分支在同一位置做了不同修改，而它自己又没有上帝视角，不知道你们俩谁才是对的，于是停下来，把你叫过来当裁判。

Git 不是改不了，而是不敢瞎改。这就像两个人同时改同一份 Word 文档的同一段文字，提交的时候 Word 不可能自动判断该保留谁的版本，只能列出两个版本，让你来拍板。Git 冲突的本质就是“合并过程中，两个分支对同一块内容产生了分歧，Git 需要人类介入裁决”。

搞清楚这一点，心态上就先稳了。你不会因为冲突丢掉代码，两个版本的改动其实都还在，你的任务不过是从中挑出一个正确组合，甚至按需把两边的内容都保留下来。

2.2 合并到底在比什么：三方对比模型

要真正理解冲突，我建议你先忘掉“冲突”这个字眼，把一个核心姿势刻在脑子里：Git 合并（merge）永远是一次三方对比（three-way merge）。

什么叫三方？假设你在 main 分支上，要把 feature 分支合并进来：

• 第一个版本：两个分支的“共同祖先” commit（记为 base）；
• 第二个版本：当前所在分支的版本（记为 HEAD，也就是 ours）；
• 第三个版本：被合并进来的分支版本（记为 theirs）。

Git 拿这三份内容做逐行对比。如果 base 到 HEAD 没变过，而 base 到 theirs 改了某些行，那 Git 可以直接采用 theirs 的改动；反过来，如果只有 HEAD 改了，那就保留 HEAD 的改动；如果两边在同一行各自都做了不同的修改，Git 就没办法自动抉择了，于是抛出冲突。还有一种情况是两边都新增了同一行（比如都添加了同一个方法），同样会冲突。

这个三方对比模型，是所有 Git 图形客户端、IDE 冲突解决界面、命令行冲突标记的共同底层逻辑。你只要理解了它，后面看什么工具都觉得通透：所谓“解决冲突”，其实就是在三方对比的视角下，亲手把最终结果合成出来。

3. 动手之前先备好两把刷子

3.1 三个最常用的不conflicting命令

很多教程一上来就教你改文件、敲git add，但我强烈建议你先背熟下面几个命令。它们不是解决冲突时用的，而是解决冲突“之前”和“之中”用来保命的。

• git status：这个命令在任何时刻都能告诉你 Git 当前处于什么状态。出现冲突时，它会用很清晰的列表告诉你哪些文件是“both modified”（双方都改动了），这就是你的待办清单。
• git diff：不带参数时显示工作区与暂存区的差异。在冲突状态下，它会把冲突标记和双方内容一起显示出来，配合git diff --ours、git diff --theirs还可以只看某一方的改动，非常有用。
• git merge --abort：这是后悔药。只要 merge 还没 commit，随时可以执行它，Git 会干净利落地把仓库恢复到合并之前的状态，所有工作区改动也会退回。新人有时候改着改着把自己改晕了，越改越乱，最理智的选择往往是直接 abort，梳理清楚再重来。

此外还有两个查询命令，解决冲突之前建议看一眼：git log --oneline --graph --all能快速看清你当前的提交图谱；git log --merge会列出“正在合并的两个分支中，分别改过当前冲突文件的那几个提交”。有时候你并不是唯一的改动者，这能帮你定位上一次是谁动过这个文件，找他确认一下，比你自己硬猜要快得多。

3.2 准备一个顺手的工作环境

解决冲突这件事，工具极其影响体验。我现在的习惯是：命令行为主，IDE 图形化解决器为辅。两个都要会用。

如果你只用命令行，只需要一副能看清行号的眼睛和一个现代编辑器。我推荐一下 VSCode，它原生支持 Git 冲突标记的颜色高亮，冲突区域会有“当前更改 / 传入更改 / 比较更改 / 保留双方”的按钮，傻瓜式操作，对新手非常友好。

如果你在 JetBrains 系 IDE（IDEA、PyCharm 等）里工作，那优势更大。搜索栏里搜到 Git 相关的热搜词不少，很多人其实是在 IDEA 里“拉到远端代码”就跑到了冲突界面。IDEA 的冲突解决器是图形化的三方合并面板：左边是本地版本，右边是远端版本，中间是你正在拼接的最终结果。你只需要逐块点选“接受左侧 / 接受右侧 / 两个都保留”，然后手动微调中间结果就行。这个界面我在后面实操部分会给出完整截图级别的描述。

顺带提醒一下：不管用什么工具，解决冲突前建议先确保工作区是“可回退”的状态。如果你手头有还没提交的临时改动，先git stash暂存起来，冲突解决完再git stash pop弹回去。否则你的个人改动会跟合并过程混在一起，一旦出问题很难区分责任。

4. 完整实操：亲手制造一次冲突并解决它

4.1 先动手复现一次冲突

不怕丢脸地说，我第一次学解除冲突时，觉得最头痛的不是操作，而是“我怎么触发一次冲突”。搞了半天没有冲突，自然没法练手。下面从零开始，教你一次性稳定复现。

假设你准备了一个测试仓库，里面有一个calc.js文件，初始内容只有一行：

function add(a, b) { return a + b; }

然后创建两个分支，模拟两位开发者各干各的：

# 初始化仓库，提交初始版本 git init git add calc.js git commit -m "init" # 创建并切换到 feature/login 分支 git checkout -b feature/login

此时在两个分支上各自修改同一行。比如在feature/login分支上改成：

function add(a, b) { const sum = a + b; return sum; }

提交：

git add calc.js git commit -m "refactor add on feature"

切回主分支：

git checkout main

再把同一行改成另一种写法：

function add(a, b) { return a + b + 0; }

提交。现在两边的工作都建立在同一个初始 commit 上，但同一行内容已经不同。执行合并：

git merge feature/login

恭喜你，你会看到经典的提示：

Auto-merging calc.js CONFLICT (content): Merge conflict in calc.js Automatic merge failed; fix conflicts and then commit the result.

这就是最标准的复现路径。以后你想练手，任何时候都能快速搭一个这种最小化实验环境。

4.2 把冲突标记读透：<<<<<<< ======= >>>>>>> 的玄机

冲突发生时，Git 会把冲突文件的内容改成一种“带有标记”的状态。打开calc.js，你会看到长这样：

<<<<<<< HEAD function add(a, b) { return a + b + 0; } ======= function add(a, b) { const sum = a + b; return sum; } >>>>>>> feature/login

请把这个当密码表一样背下来：

• <<<<<<< HEAD到=======之间的是**当前分支（ours）**的版本，也就是你合并前所在分支上的内容；
• =======到>>>>>>> feature/login之间的是**被合并进来的分支（theirs）**的版本；
• 每一处冲突都会有这么一组完整标记。

你要做的就是把整段标记连同冲突内容一起改写，留下你认为正确的最终版本。比如决定两边都保留一部分：

function add(a, b) { const sum = a + b + 0; return sum; }

然后把这些标记行（<<<<<<<、=======、>>>>>>>）彻底删掉。记住：最终提交的代码里，绝对不能残留任何冲突标记。常见的一个坑是文件太多，改花了眼，结果把>>>>>>>这种东西留在代码里，那编译或者 lint 必然爆雷。

4.3 手工完成合并并提交

冲突标记搞完，接下来就是三步走：

# 1. 将修改后的文件标记为“已解决” git add calc.js # 2. 确认本地合并状态，检查是否还有未解决的冲突标记 git status

这时状态会从 “both modified” 变成普通的已暂存状态。随后直接 commit，注意 commit 时 Git 已经帮你填好了一条默认的合并消息，比如 “Merge branch 'feature/login' into main”，你可以直接保存退出；如果想补充说明，也可以改成更有信息量的内容，比如 “Merge feature/login: 部分保留 login 改动”。

git commit

到这里，这次合并就算真正完成了。对于一个文件、一处冲突的场景，以上流程足够用；但现实世界往往是一个 merge 里同时冲突十几个文件，那就需要一条更稳的主线流程，我在 4.5 节会再给一套完整清单。

4.4 用 IDEA 的图形化冲突解决器

命令行流程虽然通用，但文件多的时候，图形化界面远比肉眼扫描几百个标记高效。我在 IDEA 里解决冲突的标准操作是这样的：

执行完git merge后发现冲突，IDEA 右下角会弹出通知，或者 Git 面板里文件会显示为红色。这时我打开任意一个冲突文件，右侧编辑器会自动进入合并界面：左边是本地版本（ours），中间是合并结果区，右边是传入版本（theirs），底部还有一条可拖动的变更预览条。

接下来就是逐块处理界面中用颜色标出的冲突区域。每一种冲突块，IDEA 会给你四个选项：

• 接受左边（Accept Left）：保留本地版本这一块；
• 接受右边（Accept Right）：保留传入版本这一块；
• 组合（Merge）：两个版本都拼进去，相当于把双方代码都保留，然后再手动删减；
• 比较（Compare）：左边和右边逐字对照，适合想确认差异来源时使用。

遇到一块，点一下，中间结果区会实时刷新。全部处理完之后，点击右下角的“Apply”按钮，IDEA 会在后台帮你执行git add，文件自动进入已暂存状态。之后你继续处理下一个文件，直到所有冲突文件都变成绿色，再回到 Git 面板点 Commit 提交即可。

这套图形化流程最适合多文件冲突，或者你需要频繁“保留双方改动”的场景。IDEA 那个“组合”按钮对比命令行的手动拼接，省掉不少错位风险。不管你有没有用 IDEA 的习惯，我都建议至少学会它解决冲突的界面，遇到复杂情况时能救命。

4.5 合并后千万别忘记验证

代码敲完、冲突标记清了、git add也做了，并不代表这次合并“成功了”。我见过不少人git commit之后直接git push，然后 CI 红一片。别忘了：你刚才是在“裁判”一份连 Git 都无法替你决定的内容，你组合出来的代码逻辑上有可能是有问题的——比如两边分别改了同一个函数的不同调用点，你合并后虽然语法正确，但行为却违背了预期的业务逻辑。

所以我的习惯是，任何 merge 冲突解决后，至少做三件事：

1. 因为多数冲突发生在代码层面，我至少会跑一次本地编译或单元测试，确认没有语法错误、没有把标记行残留进去；
2. 针对合并时有争议的逻辑，自己再走一遍关键代码路径——简单说就是打开相关文件，看看组合逻辑是否符合合并双方的意图；
3. 然后才提交合并，推送代码。

如果是大项目，本地全量测试跑不动，那至少要把你改过的文件跑一遍相关测试。没有编译通过的 merge，坚决不要 push。

5. 高频场景拆解：不止“同一行改两遍”

5.1 五种最常见的冲突类型速查

现实中的冲突远不止“同一行改两遍”这么简单。我整理了一个速查表，都是我这几年来高频率遇到的类型：

大多数人的第一反应是“内容冲突”，但我建议你把后几种也放进视野，特别是行尾符冲突，非常坑。Windows 默认 CRLF，Linux 和 macOS 默认 LF，如果仓库里没有.gitattributes统一规则，你拉一个文件下来没动几行，commit 之后合并会发现一片冲突，因为 Git 认为整文件所有行都变了。这种“假冲突”最浪费生命。

5.2 二进制冲突：不能用编辑器直接合并的文件

二进制文件（图片、设计稿、DLL、打包产物）冲突时，你没法打开编辑器去看<<<<<<<标记，因为标记根本不存在。Git 会提示：

CONFLICT (binary): logo.png deleted in feature/login and modified in HEAD

态度很明确：你自己去人工处理，Git 不会帮你合并。

常规做法是决定保留哪一份：git checkout --ours logo.png或者git checkout --theirs logo.png，然后git add。但我在实际中更推荐的做法是：去和改动文件的人对一下，明确两份二进制的差异目的，让设计师或产品重新导出一份最终版提交，而不是随便选一个。因为两个版本可能一个是加了个按钮，一个是换了套配色，你的“保留我方”很可能把对方的成果丢掉。

5.3 Rebase 时的冲突又不一样

说到冲突，很多人没意识到 merge 和 rebase 的冲突处理在命令行上“长得一样”，但背后的心流完全不同。git merge是一次合并两个分支，冲突解决后commit就行；而git rebase是把当前分支的若干提交，逐个重新嫁接到目标分支之上，因此它会在你的每一个提交上依次检查冲突。

这意味着，一次 rebase 过程中可能出现多次冲突：第一个提交有冲突，解决完git add后，执行git rebase --continue，Git 继续去处理下一个提交，可能又冲突了，又要解决一次，直到所有提交重放完毕。每一次解决的都是“当前这个提交与目标分支之间的差异”，场景可能完全不同，需要保持耐心。

需要特别提醒的一个操作是，如果你在 rebase 过程中感到局面失控，不要慌，别去手动乱删.git/rebase-merge这种目录。直接执行git rebase --abort，你当前分支会回到 rebase 之前的状态，什么都没有损失。很多新人不知道这个后悔药，硬着头皮在那里手工 commit 一堆半成品，最后把历史搞得一团糟。

6. 常见问题与排查技巧实录

6.1 我在实际操作中踩过的坑

第一个坑：冲突文件里挑完了标记，却忘了git add就直接 commit。Git 在这种情况下不会让你提交，会提示 “You have unmerged paths”。正确的招呼手法是先 add 再 commit。新手总在这里卡住，觉得明明改好了为啥不让提交。记住：在 Git 的眼里，“文件没乱”和“你确认过文件没问题”是两回事，add 就是你的“确认”动作。

第二个坑：合并到一半，手滑把别人的分支删了，或者忘记了当前在哪个分支。解决方案仍然是一套：git status看状态；用git branch --show-current确定当前分支；如果操作混乱就直接git merge --abort，从头再来。别靠记忆，靠命令输出。

第三个坑：解决冲突时不小心把别人的改动全部丢弃，典型的例子是 leag cy 团队只能从头手拼代码。原因是某些图形工具里面“接受左边”可能意味着“完全不用右边”，而你根本没意识到它把所有文件都覆盖了。我的对策是用git diff --ours --stat和git diff --theirs --stat先看看双方各改了哪些文件，确认每个文件确实需要保留哪一方，再做批量操作。

6.2 常用排查对照表

这个表其实也是我自己的“速查清单”。真正遇到问题时别去搜索引擎现查，先把表过一遍，多数操作都能自己拿下来。

6.3 三个减少冲突的团队小习惯

最后一个部分，我想聊聊“如何让冲突出现得少一点”。说实话，冲突无法彻底避免，但完全可以大幅减少。我自己经历过几个项目，从三天两头冲突，到后来几周碰不上一次，靠的就是下面三个习惯：

1. 小步提交、尽早合并。每次提交尽量小，改动点尽量少，分支随时和主干保持同步。合并不频繁，并不代表冲突更少，而是每次冲突拆小之后解决成本低得多。反之，一个分支闷头写了两周的代码，合回来时一冲突就是成百上千行，谁也招架不住。
2. 模块拆分做清楚。两个团队尽量不要频繁地修改同一批文件和函数。前期做好代码分层和接口划分，比你后期花时间解冲突划算得多。
3. 用git pull --rebase代替直接git pull。直接git pull会生成一条多余的 merge 记录，让历史变脏；用 rebase 会让本地提交干净地“长”在远端提交之上，是保持线性历史的现代化做法。不过要注意，rebase 会改写提交哈希，只适合处理你自己本地还没推上去的提交，一旦提交已经推到公用分支，就不要用 rebase 去动了。

7. 一些写在最后的个人体会

我个人在实际操作中的体会是：解决 Git 冲突，技术本身其实只占一半，另一半是稳定的心态和清醒的判断。很多人一看到冲突就紧张，手忙脚乱地在所有文件里反复试，反而搞出更多问题。我的习惯是：先把git status拉出来看一遍，明确冲突文件清单，然后从最简单的文件开始解决，每解决一个就git add一个；遇到不确定的取舍，绝不硬猜，去和改动过的同事确认一下意图，通常三十秒就能说清楚，省下的却是半小时的返工。

再分享一个小技巧：如果你在合并过程中临时想对比“解决前”和“解决后”的效果，可以用git stash把半成品暂存，或者先复制一份冲突文件到项目外的临时目录，留作对照。很多复杂合并中出现的问题，其实不是内容问题，而是“我改到一半忘了最初是什么样”。

还有一点挺重要的——别怕亲手制造一次冲突。你在学习的时候，刻意创建两个分支，故意在同一行做相反的修改，然后反复 merge、abort、rebase，直到所有过程都烂熟于心。Git 是把双刃剑，熟练之后它就是你项目里最可靠的保险丝；而如果你对它一知半解，它也能让你一个下午都耗在恢复代码上。所以，宁可花一个小时练习冲突解决，也不要把隐患留到上线前一天爆出来。希望这篇里写到的流程、经验和小坑，能帮你少走一段弯路。