神秘巨星z第一次在编辑器里看到一行 <<<<<<< HEAD 时，很多新人都会有一种身体被掏空的感觉：是不是我哪条命令写错了？是不是整个项目要重新拉一遍？代码是不是已经全毁了？
坦白说，这不是程序崩溃，也不代表你的工作出了大问题。这是 Git 在合并（merge）分支时，碰上了一个它没法替你拿主意的 merge conflict（合并冲突），于是把决定权原封不动地交到了你手上。那一串尖括号和 HEAD，不是系统在骂你，而是 Git 在文件里画了一个路标：这里有两份都对不上的代码，到底留谁，你来说了算。
这篇文章就围绕这个让无数新人当场破防的瞬间展开，我会从冲突标记怎么读、冲突怎么产生，到第一次实战怎么处理，再到我这些年见过的各种奇葩冲突现场，完整过一遍。不管你是刚学 Git 的新手，还是已经被冲突折磨过几轮的准老手，这篇都值得读完。
1. 屏幕变成战场：<<<<<<< HEAD 出现的那一秒发生了什么
1.1 先看懂那段“乱码”到底在说什么
先别慌，我们看一眼真实的冲突标记长什么样。
假设我正在 feature/login 分支上做登录功能，同事在 main 分支上改了同一个文件 index.js。两边都在同一段代码附近做了改动，Git 自动合并失败，于是我打开文件，看到的可能是这样：
javascript复制function init() {
// 这里开始冲突
<<<<<<< HEAD
console.log("登录模块初始化，加载用户信息");
userStore.fetch();
=======
console.log("初始化用户数据，包含历史记录");
historyStore.load();
>>>>>>> main
renderPage();
}
看起来像乱码对吧？其实每一段都有含义：
<<<<<<< HEAD到=======之间：是你当前所在分支（也就是 HEAD 指向的分支）里的内容。=======到>>>>>>> main之间：是你要合并进来的那个分支（这里叫main）里的内容。- 最后的
>>>>>>> main：标记着第二个版本结束，main就是对方分支名。
换句话说，Git 没有删掉你的任何代码，它把你这边的版本和对方那边的版本都完整地放在了同一个文件里，用分隔线隔开，逼你做个选择。
在 VSCode 里，这部分会显示成 "Current Change" 和 "Incoming Change" 两个可点击的选项，还会给你 “Accept Current Change”（保留当前分支的）、“Accept Incoming Change”（保留合并进来的）、“Accept Both Changes”（两个都保留）这类快捷按钮。但在命令行、Sublime、或者没有装插件的编辑器里，你看到的就是最原始的尖括号文本。
1.2 新人崩溃的真正原因不是标记本身
我见过不少新人，遇到这种情况第一反应是“代码坏了”，然后直接找组长说“项目被我搞崩了”。
这其实是误解。你看到的不是报错，而是 Git 给你留的一道“选择题”。冲突意味着 Git 已经尽力把两边改动都拼在一起了，但有一处或者多处改动，它实在没法判断取舍——因为两个分支在同一个位置写了不一样的内容。这时候它不能擅自决定，否则很容易把某个人的逻辑悄悄丢掉，所以只能停下来，等你人来裁决。
所以，<<<<<<< HEAD 不是“死神的宣告”，更像是 Git 贴的便利贴：这几个地方我拿不准，你确认一下。
真正让新人崩溃的，是那种“不知道怎么处理”的无助感。因为学校里教的 Git 流程通常都是 add、commit、push 一条龙，很少有老师真的带你撞一次冲突。第一次面对这种满屏尖括号的文件，谁都会怀疑人生。我当年第一次看到这东西，第一反应也是把文件关掉，想重新 clone 仓库。
但问题就在这里：冲突不会因为你重新 clone 就消失。你重拉一遍，合并该冲突还是冲突。只有学会处理它，才算真正开始用 Git 协作。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 冲突是怎么来的：Git 合并的本质和“三个版本”的博弈
2.1 HEAD 是什么？它为什么出现在冲突标记里
要理解冲突，先得认识 HEAD。
在 Git 里，HEAD 就像一个“当前所在位置的指针”，它指向你正在检出的那个提交。你执行 git branch 时看到的分支名旁边带着 * 的那个分支，就是 HEAD 指向的分支。
所以当冲突标记里写着 <<<<<<< HEAD 时，翻译成人话就是：下面这段内容，来自你现在所在的这个分支版本。
举个例子，你执行了 git merge main，当前分支是 feature/login，那么这次合并中，HEAD 代表的是 feature/login 分支上的代码，而 >>>>>>> main 代表的是被合并进来的 main 分支的代码。这个标识不复杂，但新人往往卡在“HEAD 到底是谁”这个问题上。记住一句话：HEAD 永远是“你现在站的这个位置”。
2.2 三路合并：Git 不是不会用，是你给了它一道选择题
为什么 Git 不能直接自动合并？这里要讲一个听起来有点绕、但理解之后所有冲突都豁然开朗的概念：三路合并。
假设两个分支从同一个提交点分开，这个共同祖先提交我们叫它 Base。现在你这边改了一部分，对方那边改了另一部分。Git 合并时，会拿 Base 和你的版本比，再拿 Base 和对方的版本比，这个过程就是三路合并里的“三路”：Base、ours（你的）、theirs（对方的）。
如果你们两边改的是完全不同的区域，Git 可以很聪明地把两个版本组合起来，不需要你插手。但问题在于，如果你们两边都改了同一片区域，而且改得还不一样，Git 就不知道“以哪个为准”了。
用生活化的类比：你和室友合租，冰箱里有一盒牛奶。你俩各自回屋待了一周，你采购时往盒子里加了两瓶酸奶，他采购时往盒子里加了一瓶果汁。等你们再见面，这盒“牛奶”里到底该装什么？没有人能替你决定，因为你俩都动过这个盒子，而且动的方式不一样。Git 同理：同一份文件的同一个位置，两边都写了不同的内容，它自然没法自动选。
你可以理解成，Git 本身并不“笨”，它只是不想因为自动选择而埋没任何一方的修改。自动合并不了，它就停下来给你报一道选择题。这是设计上的温柔，不是设计上的缺陷。
2.3 什么情况下 Git 才需要你“亲自下场”
并不是所有合并都会产生冲突。绝大多数情况下，两个分支改的是不同文件，或者同一个文件的不同位置，Git 都能安静地自动合并，你连冲突长什么样都不知道。
真正会触发冲突的通常是这几类情况：
- 两个分支改了同一个文件的同一行，且内容不同。
- 两个分支改了同一个文件的相邻位置，导致 Git 无法确定插入顺序。
- 一个分支删除了某个文件，另一个分支还修改了这个文件。
- 二进制文件（图片、Excel、PDF 等）被两个分支同时修改了。
- 整个文件的行尾符或编码被整体改变，导致 Git 认为每一行都变了。
后面我会在第四部分详细聊这些现场。现在你只需要记得：冲突不是“你操作错了”，而是“多人协作下代码演化方向产生了分歧”，这是一个完全正常的流程节点。
3. 第一次处理冲突的完整流程：从心跳加速到顺利提交
3.1 第一步：别急着改文件，先看 git status
你看到冲突标记之后，第一件要做的事不是去编辑器里乱改，而是先回到终端，运行一条命令：
bash复制git status
这条命令会告诉你当前处于什么状态。在冲突中，它会显示类似这样的信息：
code复制Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: index.js
both modified 的意思是：这个文件两个分支都动过，目前处于“未合并”状态。Git 不会让你在这种情况下直接 commit，因为它还没收到你“我已经处理完了”的信号。
这一步的核心作用是让你心里有数：到底有几个文件冲突？都是哪些？如果是几十个文件冲突，你得有心理准备，这可能是大工程；如果只有一两个文件，很快就能搞定。
顺便提醒一句：如果冲突文件很多，不要慌着一头扎进编辑器。先把文件名全部记下来，或者用 git status 的输出心里排个优先级，优先处理关系到程序能不能跑的入口文件，再去处理边角料。
3.2 第二步：打开冲突文件，逐处判断“留谁”
接下来打开有冲突的文件，搜索 <<<<<<< 标记。不同编辑器搜索方式不一样：
- VSCode：用
Ctrl+F或Cmd+F，输入<<<<<<<。 - Vim：输入
/<<<<<<<回车。 - Sublime：同样用搜索面板搜
<<<<<<<。
搜到之后，逐处解决。解决的逻辑其实很简单，你只需要判断这三件事：
- 这段功能逻辑是我这边的才有的，还是对方那边才有的？
- 两个版本是不是表达了同一个意思？如果是，哪个写法更符合当前需求？
- 两边不是一回事，但都需要，能不能把两段代码都保留？
手动编辑的时候，把不需要的分隔标记和对应内容删掉，只留下你想保留的代码。比如上面那个 init() 的例子，如果确认两边的日志都要保留，可以改成：
javascript复制function init() {
console.log("登录模块初始化，加载用户信息");
console.log("初始化用户数据，包含历史记录");
userStore.fetch();
historyStore.load();
renderPage();
}
记得把每一处的 <<<<<<< HEAD、=======、>>>>>>> main 三行全部删干净，只留下最终的代码。这一步特别容易漏：新人常常解决了第一处就兴高采烈去提交，结果文件里还残留着第二个 >>>>>>>，Git 还是会说你没有解决完。
如果你用的是 VSCode，可以直接点 “Accept Current Change” 或 “Accept Incoming Change” 按钮，相当于自动帮你删掉标记并保留对应部分。但我建议第一次接触冲突的人，至少手动玩一次，知道按钮背后实际发生了什么，以后出问题时才不会两眼一抹黑。
3.3 第三步：告诉 Git“问题解决了”并完成提交
当你把文件里所有冲突标记都清理干净，代码整理成你满意的最终版本后，需要执行：
bash复制git add index.js
git add 在这里的含义是：告诉 Git，这个文件的冲突我已经处理完了，你可以把它标为“已解决”。这一步很多人不理解，为什么提交前还要 add 一次？因为在合并过程中，Git 不允许直接把未解决的文件提交上去。add 就是你向 Git 确认“我搞定了”的仪式。
确认所有冲突文件都 add 完成之后，执行提交：
bash复制git commit
Git 会打开一个编辑器，里面已经预填好了合并提交信息，通常是 “Merge branch 'xxx' into yyy” 之类的内容，你直接保存退出即可。
到这里，这次合并就算完成了，你成功把两个分支的内容合在了一起，冲突也被你亲手解决了。
3.4 中途后悔了怎么办：abort 是你的后悔药
很多新人第一次处理冲突时，因为心情紧张，改到一半发现情况越来越乱，担心把文件改坏了。这时候请记住：Git 给你留了后悔药。
如果这次合并是你主动执行的（比如 git merge main），而且你还没提交，你可以随时跑：
bash复制git merge --abort
这个命令会立刻中止这次合并，把工作区恢复到合并开始之前的状态。你刚才改了一半的冲突文件，也会被还原成没合并前的样子。不要担心这些操作会把代码弄丢，--abort 只是“撤销这次合并”，不会影响你之前已经提交的所有内容。
如果你是执行 git pull 时拉进来的远程合并，同样可以用 git merge --abort 来撤销。还有另一种常见情况是 git rebase 过程中出现冲突，对应的撤销命令是：
bash复制git rebase --abort
区别在于，rebase 的冲突标记长得一样，但背后的机制不同，处理完冲突后你要执行的是 git rebase --continue，而不是 git commit。这个我在第五部分再展开。
4. 比“看到 HEAD”更磨人的现场：我踩过和解过的常见冲突类型
4.1 两个人改了同一行：最基础但也最容易扯皮
这是最典型的冲突场景：你和同事的代码改动落到了完全相同的行上。
比如一个配置文件里，你们都修改了某个超时时间的参数。你改成 30，他改成 60，Git 合并时直接给出冲突。这种冲突技术上不难解决，难的是人的沟通：到底以谁为准？如果两个版本都是有意改的，但语义冲突，你硬选一个，可能导致功能行为不符合预期。
我的经验是：这种冲突一定要去问对方，尤其是参数类、配置类的改动，不能自己拍脑袋定。因为超时时间这个值，可能对方正在等其他服务的响应时间调整，你改了 30，他那边所有测试都会跟着挂。
4.2 格式化大战：为什么一次换行符变更能带来几百个冲突
比“改同一行”更磨人的，是“整个文件都被改了一遍”的假象。
有的同事习惯在 Windows 上开发，编辑器保存时默认用 CRLF 换行；你在 macOS 或 Linux 上，默认是 LF 换行。一旦某次合并中，有一方把整个文件的行尾符改了，Git 就会认为这个文件“每一行都变了”，于是和你改过的局部内容产生海量冲突，看起来就像所有人都往同一个文件里塞了代码。
格式化工具也是重灾区。有些项目早期没有统一 Prettier 或 ESLint 规则，某天突然有人提交了一版全项目自动格式化，结果所有并行分支在合并时全部爆炸。
这种冲突处理起来非常费神，因为它不是你代码写错了，而是版本之间的“格式基线”发生了漂移。我见过最夸张的一次，一个冲突文件有两千多行，其中一千八百行都因为换行符被标成冲突，人肉改根本不可能。
应对格式类冲突的经验：
- 不要急着手动刷冲突，先看是不是换行符或缩进差异。用编辑器把文件先转一次行尾符（比如统一转成 LF），然后重新
git add，很多冲突会自动消失。 - 项目里尽早统一格式化方案，提交
.editorconfig、.prettierrc，让所有人用同一套规则。 - 如果你发现有人提交了一大坨纯格式化改动，尽快提醒他单独提交，不要夹带在功能提交里，否则未来每次 merge 都是灾难。
4.3 删除与修改的对峙：有人删了文件，有人还在改
还有一种很隐晦的冲突：分支 A 里有人把某个文件删了，分支 B 里另一个人还在改这个文件。合并时 Git 会提示 deleted by us 或 deleted by them。
这种场景下，Git 不会像普通冲突那样把两段内容都放在文件里，而是直接在目录里把这个文件标记成了“丢失”状态。你需要决策：这个文件最后到底应该存在，还是应该被删掉？
如果功能已经废弃，文件该删，那就直接确认删除。如果只是某个人为了重构把它挪了位置，那么单纯的删除可能丢掉代码，你需要找回文件，恢复到一个合理的位置。
具体操作时，可以用 git log 去查这个文件的变更历史，搞清楚它以前是干什么的，再决定去留。千万不要一看到 deleted 就直接 git rm，你可能把还没合并进来的功能一起删了。
4.4 二进制文件的无奈：Git 不是不能合并，是真“看不懂”
文本文件冲突，你还能打开文件看看内容。但遇到图片、Excel、PDF 这种二进制文件冲突，Git 根本没有自动合并的办法，它只会告诉你：这个文件两边都变了，我没办法，你二选一吧。
比如两个前端同时改了一张图标切图，一个改成蓝色，一个改成红色，Git 在合并时压根不知道你俩谁是谁，于是直接把文件标记成冲突，并且不会提供任何内容对比。
处理二进制冲突，我的建议很简单：先问对方他改的是什么，你的改的是什么，再决定用哪个版本。
如果确定要保留某个版本，可以执行：
bash复制git checkout --ours 图片.png # 保留当前分支的版本
git checkout --theirs 图片.png # 保留合并进来分支的版本
然后 git add 图片.png 标记解决。这里再提一句：如果项目里经常有人同时改设计稿、Excel 或其他二进制文件，最好约定一下，每个人负责的文件尽量别同时动，能有效减少这类无效冲突。
5. 给新人的实操建议：冲突不可怕，可怕的是在冲突面前瞎操作
5.1 解决冲突的几条铁律
这些年我处理过很多冲突，也带过不少新人，总结下来，最实用的经验并不是哪条命令，而是几条几乎不会出现在官方文档里的“纪律”：
- 第一，不要慌。 冲突不会让代码消失，所有版本都静静躺在文件里，你有足够的时间去处理。你越慌，越容易手滑把两段代码都删了。
- 第二，不要只删标记不删多余代码。 有些人遇到冲突，为了快点消掉红色的提示，把所有尖括号行删掉，然后把两边的代码原封不动都留着。结果一段代码被定义了两次，程序直接跑不起来。
- 第三，先理解再动手。 如果你没看懂冲突双方各自的意图，宁可不解决，去问人。宁可多花半小时问清楚，也比搞出一个隐性问题强。
- 第四，解决完一个文件再 commit 一个。 很多人喜欢把所有文件一次性解决完再提交，但一旦中间思路被打断，容易遗落某个文件。我的习惯是：每个文件处理完就
git add，最后再统一提交，这样我可以随时用git status看到还剩几个没解决。 - 第五，不确定的时候，
git blame和git log是你的好朋友。 冲突文件不是你一个人的代码，去查一下这两行是谁加的、提交说明是什么，能帮你快速理解原始意图。
5.2 新人最容易慌的五个瞬间和应对方式
根据我带人的经验，新人遇到冲突最容易慌的典型瞬间大概有五个：
瞬间一：git pull 拉代码，结果进入了类似 Vim 的编辑界面，整个人就懵了。
这不是冲突，这是 Git 在让你输入合并提交的信息。你在 Vim 界面里按 :wq 回车，就能正常退出。但如果你是第一次看到这个界面，很容易以为卡死了，甚至直接关终端。
其实如果你不是特别想合并远程分支，这里有个更温和的方式：git pull --rebase。这句会把你的本地提交先放到一边，拉远程代码，再把你本地提交重新放回去。如果此时有冲突，解决的逻辑和普通 merge 稍不同，但不会生成一个无谓的 merge commit。
瞬间二：处理一个文件到一半，突然找不到冲突标记了。
有时候你解决了几处，但还有一个残留的 >>>>>>> 藏在文件很下面的地方，搜索都没找到。建议在编辑器里搜 <<<<<<< 和 >>>>>>> 两个字符串，分别搜一遍，如果两边都搜不到，这个文件才算干净。
瞬间三：rebase 冲突时，不知道如何处理完再继续。
git rebase 的冲突和 git merge 的冲突长得一样，但提交方式不同。merge 冲突解决后是 git add + git commit，rebase 冲突解决后是 git add + git rebase --continue。
如果你在 rebase 过程中执行了 git commit，Git 会提示你“不需要手动 commit”，因为它本来就要帮你重新做提交。这个差异我踩过两次才彻底记住。
瞬间四：因为怕冲突，天天不敢 pull 远程代码。
我见过不少新人，为了避开冲突，刻意不在工作区更新远程代码，攒两周才敢 pull 一次。结果一 pull，因为积压的差异太大，冲突直接爆炸。
正确做法是：高频、小步地 pull 和 merge。每天开始工作前先 pull 一次，写完一个小功能就 push 一下，别让分支之间差异拉得太大。冲突越早发生，解决起来越轻松。
瞬间五：看到冲突文件太多，干脆想删掉仓库重来。
重新 clone 确实能解决“仓库本地状态乱了”的问题，但解决不了“两个分支的代码合不到一起”的结果。甚至会因为重 clone 丢掉本地未提交的内容。所以遇到海量冲突时，不要想着推倒重来，而是要按我上面说的：先看 status，再按文件分步处理，或者找一个更懂的人帮你过一遍。
5.3 我的体会：冲突是一次“被迫读懂别人代码”的机会
我不是想强行灌鸡汤，但说实话，我带过那么多新人，凡是能静下心来认真处理几次冲突的人，对代码仓库的理解都会上一个台阶。
因为冲突逼着你必须仔细读两边的代码，搞清楚哪一段是什么逻辑、为什么会有分歧、两个分支的设计意图分别是什么。这种“被动阅读”虽然难受，但比你自己刷十遍文档都管用。相反，那些见冲突就找人帮忙、自己从来不碰的人，三年后遇到冲突还是那个手忙脚乱的样子。
我个人带新人的习惯是：第一次遇到冲突，我会在旁边看着，让他自己读标记、自己判断、自己动手改。只有当他真的卡在某个逻辑判断上时，我才会给建议。这个过程很慢，但成长非常明显。等他自己处理完两三次之后，我再告诉他一句话——以后你再看到 <<<<<<< HEAD，不要再觉得是系统坏了，你要知道，这是 Git 在给你递小纸条：这边代码你来定。