黄小秋有人在群里发了一张截图，代码文件从第30行开始，密密麻麻全是 <<<<<<< HEAD、=======、>>>>>>> feature/login，配着一句话：“我这几天写的东西是不是全没了？”后面跟着一串崩溃表情。
这个场景我见过太多次了。几乎每个刚接触 Git 的开发者，都会在某次 git pull 或 git merge 之后，第一次面对这个“三行夹心”的冲突标记。说实话，第一次见到它的时候，大多数人脑子里想的不是“Git 需要我做决定”，而是“完了，代码坏了，要重写了”。
其实你看到的不是灾难，而是 Git 在告诉你：它已经尽力把两边能自动合并的都处理完了，剩下的这块内容它没法替你拍板，需要你亲自来定。这篇文章就从那个让人头皮发麻的 <<<<<<< HEAD 讲起，把冲突标记、HEAD 指针、合并（merge）的底层机制全部拆开，再给出一套可以直接照着操作的完整处理方案。不管你是第一次遇到冲突的新人，还是想给团队新人讲清楚 Git 冲突的老手，这篇都值得看完。
1. <<<<<<< HEAD 到底在说什么：冲突标记的逐行解剖
1.1 先看一个标准的冲突现场
假设你正在 dev 分支上开发，执行 git merge feature/login，结果 Git 提示冲突。打开编辑器，会看到这样的内容：
text复制<<<<<<< HEAD
const handleLogin = (values) => {
console.log('本地版本：走手机号登录');
loginByPhone(values);
};
=======
const handleLogin = (values) => {
console.log('合并版本：走账号密码登录');
loginByPassword(values);
};
>>>>>>> feature/login
这个结构看起来像什么？像一份文档里被插入了一组“批注”，批注用特殊的标记把两段内容框了起来。这三行标记的含义其实非常直接：
<<<<<<< HEAD：冲突区块开始，下面紧跟的是你当前所在分支（HEAD 指向的那个提交）里的代码。=======：分隔线，上面是“我方”，下面是“对方”。>>>>>>> feature/login：冲突区块结束，后面跟的名字是正在合并进来的分支。
所以上面这段冲突，翻译成人话就是：在 handleLogin 这个函数里，你当前分支写的是“手机号登录”，feature/login 分支写的是“账号密码登录”，两边都改了同一个地方，Git 无法判断哪个才是你想要的，于是把两种版本都保留在文件里，等你来做选择。
1.2 HEAD 在这里扮演的角色，绝不是一个“奇怪的英文单词”
很多新人看到 HEAD 的第一反应是困惑：“HEAD 是谁？为什么要用我的代码和它比？”这里有个关键点必须讲清楚：HEAD 不是某个人，也不是“错误标记”，它是 Git 内部的一个指针，永远指向你当前检出的那个提交。
拿生活类比：你在电脑上打开了一个 Word 文档，光标停在某个位置。HEAD 就相当于 Git 世界的“光标位置”，它明确告诉 Git 工具链“用户现在站在这里”。当你 git checkout dev 之后，HEAD 就指向 dev 分支的最新提交；你 git switch feature/login，HEAD 又跟着飘到那边去了。
在冲突标记里，<<<<<<< HEAD 的意思是“这一段是来自你当前光标位置所在分支的代码”。所有 Git 命令、IDE 的 Git 插件、可视化工具，都是通过 HEAD 来确定“你我的版本”的。理解这一点，你对 Git 的整体认知会上一个台阶。
1.3 为什么 Git 不直接把冲突“智能合并”掉
这是新人最容易产生的一个疑问：“Git 不是号称分布式版本控制工具吗，怎么连这种合并都搞不定？”
要回答这个问题，先得了解 Git 合并的本质。合并不是简单地把两边文件拼在一起，而是基于一个三方合并的模型：
- base：两个分支分叉之前的共同祖先版本；
- ours：你当前分支的版本；
- theirs：你要合并进来的那个分支的版本。
Git 会同时比对这三份内容。如果某个区域只有一方改动，Git 直接采用改动后的版本；如果两边改的是完全不同的文件或同一文件的不同区域，Git 也能自动合并；只有当两边在同一个位置都做了修改，且修改结果不一样，Git 才无法求解，只能抛出冲突。
这样设计是有道理的：const title = '本地标题'; 和 const title = '远程标题'; 这两行，程序员的业务意图是“以哪个为准”，Git 不可能凭空替你决定。它宁可把问题摆在明面上，让你来做这个决策，也不要悄无声息地丢代码。冲突标记是 Git 的“暂停键”，不是“错误报告”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 新人崩溃的根源：不是冲突本身，而是这三个认知盲区
2.1 盲区一：“我的代码全没了”的恐慌
我见过太多新人看到冲突后的第一反应：疯狂往上翻文件、找垃圾桶、查备份。他们以为 Git 把代码覆盖掉了。实际上，代码一行都没有丢。冲突标记只是以文本形式插在了文件里，把冲突双方的内容完整地排列出来了。你之前写的代码还躺在 <<<<<<< HEAD 和 ======= 之间；对方写的代码在 ======= 和 >>>>>>> 之间。
为什么会有“代码没了”的错觉？因为大多数人第一次看到的是“文件里多了很多莫名其妙的符号”，潜意识里觉得文件被破坏了。这里送你一个定心丸：冲突是文件层级的事件，不是数据库层面的灾难。只要你不执行 git reset --hard 之类的破坏性命令，所有提交历史里的代码都还在。
2.2 盲区二：“为什么别人的代码会出现在我的文件里”
新人对分支模型的理解，往往停留在“分支就是文件夹的副本”这个粗糙认知上。当他们在一个分支里看到另一个分支的代码时，会觉得“被入侵了”。这其实是因为没理解 Git 合并的真实过程。
Git 的仓库是一个提交图，每个分支只是指向某个提交的标签。合并操作做的事情，是把两个分支各自指着的提交，连同它们分叉以来的所有历史，按照“共同祖先”这个基准进行一次三路合并。所以当你把 feature/login 合并进来，你本地出现对方分支的代码是完全正常的，因为 merge 就是在做“把两边的改动揉到一个工作区里”这件事。
2.3 盲区三：把命令行提示和 IDE 界面当成两套东西
现在的开发环境里，很多人同时开着终端、VS Code、SourceTree 这类工具。冲突发生时，终端里可能滚过几行 CONFLICT 提示，VS Code 里则弹出一堆红红绿绿的区块。两边呈现方式不一样，新人很容易慌：“我该信哪个？”
其实它们描述的是同一件事。终端的 CONFLICT (content): Merge conflict in src/App.js 和 VS Code 里的冲突区块，都是对 Git 工作区里同一个“冲突状态”的不同可视化。你只需要选择自己最顺手的一套工具来处理，处理完后统一 git add、git commit 收尾即可。工具只是展示层，真正决定冲突去留的是你自己编辑之后的文件内容。
3. 正经的冲突处理流程：按场景选择你的对策
3.1 处理前的第一件事：先搞清楚“我这里到底有几个冲突”
不要一上来就打开编辑器，逐行删标记。先跑一遍 git status，看看冲突文件的清单。一个典型的输出长这样：
text复制Unmerged paths:
(use "git add <file>..." to mark resolution)
both modified: src/components/Button.jsx
both modified: src/pages/Login.jsx
both modified 的意思是两边都改了这个文件，Git 无法自动合并。如果仓库里有几十个文件冲突，你应该做的是先评估全局，而不是钻进某个文件里埋头苦干。这能避免“解决了三小时，发现方向错了”的悲剧。
然后再用 git diff 查看冲突详情，确认冲突内容是不是都是你预期的。这时候你对整体的冲突面积就有数了。
3.2 方案 A：改到一半发现思路错了，想全部反悔
这是新人最需要的“后悔药”。如果你 merge 到一半，发现冲突太多、不想处理了，或者刚才的操作根本不是你想做的，可以用：
bash复制git merge --abort
这条命令会把工作区恢复到 merge 之前的状态。前提是你没有手动改过太多文件——它会把整个 merge 操作连同工作区改动一起回滚。如果你是在 git rebase 过程中遇到冲突，就用：
bash复制git rebase --abort
这两条命令就像游戏里的回城卷轴，能在你彻底崩溃之前把你拉回安全地带。实操中我见过有人不记得这个命令，直接 git reset --hard，结果把没提交的改动也一并清空了。记住了，纯粹的“反悔”用 abort，不要用 reset。
3.3 方案 B：只想要其中一方的代码
冲突块通常不是只有一个。如果某个文件里全是“我的代码”和“对方的代码”之争，而你明确知道这一版应该完整采用某一方的实现，那就不需要逐个区块手动改。
先明确你的分支身份：假设你在 dev 分支上，合入 feature/login，那么：
- 想保留当前分支（dev）的版本：
git checkout --ours <文件路径> - 想保留合并进来的分支（feature/login）的版本：
git checkout --theirs <文件路径>
注意：这个命令是把整个文件切换为某一方的版本，不是针对单个冲突块。适合“整个文件我都不要对方的”或“整个文件我都不要我的”的极端场景。使用之后记得 git add 标记为已解决。
提示：
--ours和--theirs的方向在 merge 和 rebase 场景下是相反的。rebase 时，ours 实际上是“你正在变基的目标分支”，theirs 才是“你正在重放的提交”。用之前一定先想清楚当前执行的是 merge 还是 rebase。
3.4 方案 C：两边都要，手动合并
这是最常见、也最需要动脑的场景。处理步骤很简单：
- 打开冲突文件；
- 编辑内容，只保留你想要的代码，删掉
<<<<<<< HEAD、=======、>>>>>>>这三类标记行； - 如果两边逻辑都需要，就把它们都留下，并调整成最终可运行的代码；
- 保存文件；
- 执行
git add <文件>； - 全部解决完毕后，执行
git merge --continue（或git commit）完成提交。
举个实际例子。假设冲突是这样的：
text复制<<<<<<< HEAD
const title = '本地项目名';
=======
const title = '远程项目名';
>>>>>>> feature/login
如果你要保留本地版本，最终文件应该是：
text复制const title = '本地项目名';
如果你两个版本都想要，最终文件可能是：
text复制const title = '项目名（以远程为准，本地保留注释）';
const remoteTitle = '远程项目名';
关键点在于：你删掉的是标记行，保留的是代码，删完之后还得检查文件能不能正常编译、有没有语法错误。我见过有人把标记删得干干净净，保存的时候发现把整段逻辑也删了一半，运行起来直接报错。
3.5 可视化工具体验：VS Code 与 git mergetool
如果冲突很多，纯手改容易遗漏标记。VS Code 这种现代编辑器会直接把冲突块高亮显示，并提供按钮：“Accept Current Change（保留当前分支版本）”“Accept Incoming Change（保留传入分支版本）”“Accept Both Changes（两个都保留）”。这本质上和你手动删标记一样，只是省去了敲键盘的时间。
如果你更习惯用终端工具做三方对比式合并，可以配置自己的 mergetool：
bash复制git config merge.tool vscode
git config mergetool.vscode.cmd 'code --wait $MERGED'
之后遇到冲突直接运行：
bash复制git mergetool
它会以“base / ours / theirs / merged”四栏视图打开一个图形化对比界面，适合比较复杂的合并场景。不过对入门阶段来说，VS Code 的冲突高亮已经足够好用了。
4. 一次真实冲突的完整排查过程：从爆红提示到文件修复
4.1 故障现场还原：git pull 时弹出的 CONFLICT 提示
某个周五下午，团队里的前端同事接到了需求，在 feature/login 分支上写了一个带表单校验的登录页，同时主分支 main 上另一个同事重构了公共请求库 utils/request.js。周五合并时，新人在自己分支上敲了：
bash复制git pull origin main
终端瞬间滚出一片提示：
text复制Auto-merging src/pages/Login.jsx
CONFLICT (content): Merge conflict in src/pages/Login.jsx
Automatic merge failed; fix conflicts and then commit the result.
这就是“崩溃”的起点。注意看提示里的三个关键信息：Auto-merging 表示 Git 已经自动合并了一部分；CONFLICT 后面是冲突文件路径；最后一行是明确的行动指引“修复冲突，然后提交”。
4.2 用 git status 和 git diff 还原完整冲突图谱
遇到这种情况，第一反应不是打开文件，而是执行：
bash复制git status
输出会明确列出所有冲突文件。然后再看具体冲突内容：
bash复制git diff
git diff 在冲突状态下展示的是“你对冲突文件未解决时的暂存区差异”，你能看到哪些区块是冲突态。如果想看单个文件的详细冲突标记，直接打开 src/pages/Login.jsx 编辑器里就能看到。
我用一个简单表格整理排查过程的命令用法，方便你对照使用：
| 目的 | 命令 | 作用 |
|---|---|---|
| 查看冲突清单 | git status |
列出所有冲突文件与操作提示 |
| 查看冲突内容 | git diff |
展示工作区内冲突与未暂存变更 |
| 查看分支提交图 | git log --oneline --graph --all -5 |
看两个分支的分岔点与最新提交 |
| 查看某文件双方历史 | git log -p src/pages/Login.jsx |
看这个文件在两边的提交记录 |
| 某行代码是谁改的 | git blame src/pages/Login.jsx -L 30,50 |
定位 30 到 50 行修改者与提交 |
4.3 定位“谁改了什么”：git log 与 git blame 双管齐下
当冲突内容涉及业务逻辑时，光看代码字面意义不够，你得知道每个版本的来龙去脉。我习惯先把分支历史拉出来看一眼：
bash复制git log --oneline --graph --all -10
这能看到两个分支在哪个提交处分叉、各自加了几个提交。如果对方分支有一长串提交，而每个提交说明写得很清晰，那构建冲突的“意图拼图”会快很多。
但如果冲突区域的代码是某一次 commit 中改的，我建议用 git blame 精确到行级：
bash复制git blame src/pages/Login.jsx -L 80,100
它会把每一行的 last-modified 提交哈希、作者、时间全部列出来。这一步看起来繁琐，实际非常有效。比如我发现冲突区域中有 3 行是上周一个同事加的类型守卫，另两行是这周新加的校验逻辑，我就知道这两者大概率是可以共存的，合并策略就变成了“两个都保留，并做顺序调整”。
在这个案例里，最终我们确认：feature/login 分支新增了表单校验逻辑，同时 main 分支的请求库重构把 submitForm 的返回值从 void 改成了 Promise<boolean>。Login.jsx 的冲突实际上来自于“校验通过后调用提交函数”这一行的两套写法。两个分支都没错，但接口调用方式要跟着新签名走。于是手动合并时，保留新分支的提交函数调用方式，并同步调整了校验后的逻辑。
4.4 解决过程中常见的二次崩溃点
冲突解决本身不算难，难的是解决过程中又踩新坑。我在实际带新人的时候，见过下面这几种情况：
-
解决完忘了 git add：手动改完文件，觉得“完事了”，直接执行
git merge --continue，结果 Git 提示还有冲突未解决。其实只是你改完没告知 Git“这个文件已经搞定了”，必须先git add把它标记为已解决，Git 才知道你完成了。 -
用编辑器全局替换把分隔符误删：有人想快速清理标记，于是用“查找替换”把
<<<<<<< HEAD替换成空字符串，却忘了=======也是个分隔符，全局替换时把正常代码里的相等判断也给换了。这种低级事故会引入新 bug。 -
只解决了一个文件就提交：如果
git status显示 5 个冲突文件，你只处理了 2 个就git commit，Git 会拒绝提交，提示“您尚未结束您的合并”。这时候要么把剩下的也处理掉，要么git commit会被阻断。强制跳过是不行的（除非用--no-verify这种非正常方式，不推荐）。 -
在解决过程中又 pull 了一次：merge 进行中的时候，工作区处于“合并状态”，此时再执行
git pull可能会让你陷入更深的混乱。建议一个合并从头做到尾，中途不要穿插其他 Git 操作。
5. 让冲突从“天天崩”变成“很少见”的工程习惯
5.1 小步提交、频繁同步
冲突不是凭空冒出来的，它和你分支分叉的时间长度强相关。分支活得越久、偏离主干越远，合并时冲突的概率和面积就越大。想让冲突少一点，最立竿见影的方法就是：小步提交，频繁同步主干。
小步提交的意思是，不要把“写了三天的一个大功能”一次性推到远程，而是拆成有意义的多个小提交。每个提交主题单一、范围可控，review 和合并的摩擦都会小很多。频繁同步主干则是说，功能分支存活期间，每隔一天甚至几个小时就 git fetch + git merge origin/main（或者 git rebase origin/main），让主干的最新改动持续流入你的分支，避免到最后才做一次性“大爆炸式合并”。
5.2 理解分支策略：长期分支和短期分支的取舍
冲突频率和团队分支策略关系极大。如果你们每个功能都开一个分支，并且分支生命周期是一周以内，冲突只会出现在少数热点文件上。如果存在维护了几个月都不同步主干的“长期功能分支”，那几乎必然在合并时发生大面积冲突。
这不是说长周期分支不能用，而是说能用短分支解决的问题不要拖长。多个功能并行时，尽量让它们改动不同的模块和文件；如果两个开发者在同一文件上改，早点合并、勤沟通，比等代码写完再对撞要稳妥得多。
5.3 减少无效 diff：格式化与 lint 的团队约定
有一种冲突极其气人：双方都没有改业务逻辑，但一个人用了单引号，另一个人改成了双引号；一个人按 4 空格缩进，另一个人保存时自动格式化成了 2 空格。结果整个文件大量冲突，看起来像世界大战，实际上毫无技术含量。
解决方案是团队级别的：强制统一的代码格式化工具（Prettier / Black / gofmt 等），配合统一的 lint 规则，并且把格式化操作纳入 Git 提交钩子。这样所有人的代码风格保持一致，diff 只包含真正的逻辑变化，冲突自然大幅减少。
5.4 merge 和 rebase 的选择，决定了你的冲突体验
这是很多人搞不清楚的进阶话题。简单说：
git merge会把两个分支的分叉历史“缝合”起来，形成一次合并提交。冲突需要一次性解决，解决后生成一个单独的 merge commit。git rebase则是把你分支上的提交“摘下来”，重新安放到目标分支的最新提交之后。如果遇到冲突，可能要逐提交解决，冲突多的时候很痛苦，但它能让提交历史变成一条干净的直线。
我的个人实践是：在个人功能分支上开发时，主动用 rebase 跟随主干，这样功能分支永远基于主干最新代码，合回去时基本不会冲突；在多人协作的集成分支上，老老实实用 merge 保留历史，方便回溯。
5.5 最后一条：别让你的冲突解决变成“沉默的合并”
冲突解决完提交了，不代表事情结束了。如果你在合并中对某个业务逻辑做了取舍（比如“以对方的实现为准”），最好在提交信息里写上：Merge branch 'main' into feature/login，然后在描述里简单说明“冲突解决：request.js 采用 main 版本，Login.jsx 校验逻辑已合并”。这会让后续翻历史的同事（包括未来的你）少掉很多头发。
我的个人体会
说句掏心窝的话，我现在看见 <<<<<<< HEAD 还是会心里咯噔一下，因为这意味着“无脑自动化的舒适区结束了，接下来要靠脑子了”。但它不再让我恐慌，因为我知道这几行标记是什么意思、我的代码不会丢、处理完该怎么收尾。
对于第一次遇到 Git 冲突的年轻同事，我的建议永远是一样的：不要自己闷头在编辑器里删标记。找一位老同事坐在你旁边，把 git status、git diff、git log 这些命令一个个跑一遍，一起讨论一下两边代码的意图，再动手改。这个过程走完一次，你对 Git 的理解会超过自己摸索十次。
如果你已经理解了冲突标记的含义，那下次再看到 <<<<<<< HEAD，不妨换个心态：这不是 Git 在跟你作对，而是它在说“我已经把能做的都做完了，接下来看你的了”。这时候你该做的，就是冷静下来，打开文件，做出那个Git无法替你做的决定。