企业官网建设流程全解析

第一次在终端里看到满屏<<<<<<< HEAD的时候，我旁边的实习生直接喊了一句：完了，代码坏了。这种反应太能理解了——一个刚学会git commit、git push的新人，面前突然冒出一大堆尖括号加英文，还夹杂着自己的代码和别人改过的代码，很难不怀疑是不是把整个项目弄炸了。作为在 Git 冲突里摸爬滚打多年的老开发，我想先给你吃一颗定心丸：这些尖括号不是错误，不是病毒，也不是 Git 坏了，它只是 Git 在明确地告诉你——这里有两份代码摆在桌上，需要你来决定留下哪一份。这篇文章我会从<<<<<<< HEAD的每一段含义讲起，带你把一次完整的合并冲突从发现、解决到提交走一遍，再把我这些年踩过的坑和排查技巧一并拆开。看完之后，下次再看到冲突标记，你的第一反应不会是崩溃，而是：哦，我该做决定了。

1. 拆开冲突标记：真相其实没那么可怕

1.1 HEAD 到底是什么，它在标记里代表什么

说到HEAD，很多初学者只记得它是 Git 里的一个名词，checkout 的时候会看到，但它的具体含义一直是模糊的。简单讲，HEAD 就是 Git 中"当前所在位置"的指针，可以理解成你游戏里的存档点：它指向你当前检出的分支或提交。当你执行git checkout dev，HEAD 就指向 dev；当你执行git checkout 某个commit，HEAD 就指向那次提交。这种设计让 Git 随时知道"你现在站在哪条代码线上"。

而在合并冲突的标记里，HEAD 代表的是你当前所在分支的版本。比如你在 main 分支上执行git merge feature/login，如果产生冲突，Git 会把冲突区域写进文件，格式是固定的：

<<<<<<< HEAD 这里是当前分支（main）上的代码 ======= 这里是合并进来的分支（feature/login）上的代码 >>>>>>> feature/login

<<<<<<< HEAD到=======之间，是你在合并之前工作区里已有的内容；=======到>>>>>>> feature/login之间，是你要合并进来的那个分支的内容。所以这个标记的实际语义是：Git 同时给你展示了两个版本的代码，让你拍板选哪边，或者决定怎么把两边融合起来。很多人一看到HEAD就以为系统出问题了，其实没有，它只是很直白地告诉你，"你当前这边"是什么。

1.2 为什么是七个尖括号而不是电脑坏了

你可能还会疑惑：为什么冲突标记是<<<<<<<、=======、>>>>>>>这种看起来像 ASCII 艺术的东西？这其实是 Git 沿用了几十年的文本冲突格式。当两个分支修改了同一个文件的同一个位置时，Git 没法判断到底哪一行才是你想要的，所以干脆不猜了，它把两份内容都原样保留在文件里，用分隔线圈出一块"争议区域"，然后把这个决定权交还给你。

用一个生活里的例子你就懂了：你和同事同时负责写一份活动方案，你写了开场白，他也写了开场白；最后你们把两份方案合成一份，但两段开场白内容完全不同。你作为负责人，不能直接把两份都贴上去，也不能随机扔掉一个，你必须自己读一遍，决定哪段合适，或者把两部分精华拼到一起。Git 的冲突标记就是那个摆在桌面上的两份草稿，七个小箭头和等号只是它的"分隔便利贴"。这个过程不是电脑坏了，也不是你操作失误，而是 Git 在并行协作中保持保守的一种保护机制。理解这一点，是你从"看到 HEAD 就慌"走向"看到 HEAD 就淡定"的第一步。

2. 冲突从哪里来：合并流程与冲突产生的三种典型场景

2.1 分支合并的工作方式

要真正理解冲突，不能只停留在"两个人都改了同一行"这种粗糙解释上，还得知道 Git 合并时到底干了什么。当你执行git merge时，Git 会做一次三方合并：它会找到两个分支的共同祖先提交（merge base），然后分别对比"当前分支在这个共同祖先基础上改了哪些内容"和"目标分支在这个共同祖先基础上改了哪些内容"。如果两边改的是不同文件，或者同一文件里互不干扰的区域，Git 会自动把两边变化都合到结果里，这个过程你不会看到任何冲突。

只有当两个分支在共同祖先之后，都修改了同一文件的同一块区域，且修改结果不一样时，Git 才知道自己没法自动决定。这个时候它就会停下来，把冲突区域用标记包起来，并告诉你"合并失败了，需要你手动处理"。注意，这里的"失败"不是你的操作失败，而是 Git 遇到了它认为不该擅自做主的场景。另外，不只是git merge会触发冲突，git pull本质上是 fetch 加 merge，也会触发；git rebase同样会产生冲突，只是表现形式不同。后面我会专门讲 rebase 的情况。

2.2 典型场景复现：两个人改同一行、同一文件、删除与修改

我来还原几个最常见的冲突现场。第一个场景：你和同事在两个分支上开发，同事在feature/login里把某个配置项的默认值从100改成了88，你同时在 main 分支上把同一行改成了120。合并的时候，Git 看到同一行有了两个新版本，冲突就出现了：

<<<<<<< HEAD maxRetryCount = 120 ======= maxRetryCount = 88 >>>>>>> feature/login

第二个场景也很常见：同事删掉了一个函数，而另一个分支上你恰好也在修改这个函数。一个分支说"这东西不要了"，另一个分支还在精细调整它，Git 没法知道你是想保留改造后的函数还是尊重删除操作，于是也标成冲突。

第三个场景是两个分支都往同一个文件的末尾追加了内容，或者同时改了文件头部的一段公共注释。这些场景的共同点是：双方修改的区域发生了重叠，且 Git 无法从代码逻辑上判断胜负。你可以把冲突理解成"并行编辑同一段音频时，两个音轨叠在一起，需要混音师决定怎么处理"，而你就是那个混音师。这张表总结了常见场景、冲突原因和处理思路：

3. 第一次实战：从崩溃到解决冲突的完整流程

3.1 发现冲突：从终端提示到 git status

很多人第一次遇到冲突，是在终端执行git merge feature/login之后，屏幕上突然蹦出一段英文，大意是Automatic merge failed; fix conflicts and then commit the result.。这时候你的第一反应可能是：失败？我是不是把仓库搞坏了？别慌，这只是一个暂停信号，Git 已经把冲突文件放进工作区，等你处理。接下来你要做的第一件事是执行git status，看看到底哪些文件进入了"未合并"状态：

$ git status Unmerged paths: (use "git add <file>..." to mark resolution) both modified: src/config.js

这里的Unmerged paths就是冲突文件列表，both modified表示这个文件在两个分支上都被改过。你还可以用git diff查看冲突细节，不过我习惯直接打开文件看标记，因为标记本身已经把两个版本摊开在眼前了。拿到文件列表之后，逐一对每个文件进行处理。记住一个原则：没有处理完所有冲突之前，不要执行 commit，因为 Git 这时不允许你直接提交，系统会提示还有未合并的文件。

3.2 编辑冲突文件：保留正确内容，删除标记

打开一个冲突文件，你会看到若干段带标记的区域。以我上面的配置项为例：

<<<<<<< HEAD maxRetryCount = 120 ======= maxRetryCount = 88 >>>>>>> feature/login

处理方式有两种选择：如果确认当前分支的120才是正确值，那就保留这行，删掉其他所有标记和对面分支内容；如果确认对方分支的88才是正确值，那就反过来。如果你发现两边都有理，比如一个改了重试次数，另一个改了超时时间，只是恰好写在同一块代码附近，那你要手动把两处改动都保留下来，变成下面这个样子：

maxRetryCount = 120 timeout = 3000

这是很多新人容易想不明白的地方：解决冲突不只是"二选一"，有时候是"把两个版本都留下，并让它们能好好共存"。所以我的实操建议是，遇到冲突时不要急着删标记，先把冲突区域前后几行代码都读一遍，了解这两段内容分别服务于什么功能，再决定保留谁、删除谁、还是怎么融合。处理完一段后继续查找下一个<<<<<<<，把所有冲突区域都清完。完成后在编辑器里全局搜索<<<<<<<、=======、>>>>>>>，确保一个残留标记都没有。残留标记一旦被提交，轻则编译报错，重则把冲突标记打进生产代码。

3.3 标记为已解决并提交：git add 和 git commit

所有冲突文件都编辑好之后，不要以为直接保存就算完事。你需要通过git add把这些文件标记为"已解决"。这一步实际是把解决后的内容加入暂存区，告诉 Git 你可以继续合并了：

$ git add src/config.js

如果有多个文件，也可以用git add .一次性暂存。然后执行git commit。注意，Git 会为你打开一个默认的合并提交信息，通常长这样：

Merge commit 'feature/login' into main Conflicts: src/config.js

你保留默认信息直接保存退出即可，也可以补充一句"解决重试次数冲突，统一为 120"。我这里不建议在这个阶段用git commit -m草草带过，因为合并提交是一个有意义的节点，信息写清楚点，以后回溯历史时会省很多事。提交完成后再执行git status，确认工作区干净，合并就算正式完成了。如果处理到一半你发现不想合并了，还有一个后悔药：git merge --abort。这个命令会把工作区恢复到合并之前的状态，非常救命。但它只适用于 merge 场景，rebase 场景要用git rebase --abort。

3.4 用可视化工具减少恐惧

如果对纯文本标记实在头大，可视化工具能让你舒服很多。比如 VS Code 在识别到冲突时，会把冲突区域用不同底色标出来，并提供几个按钮：Accept Current Change、Accept Incoming Change、Accept Both Changes。这里的 Current 对应当前分支（也就是 HEAD 一侧），Incoming 对应合并进来的分支。IDEA 和 WebStorm 也类似，进入 Merge 界面后可以逐块处理。很多人喜欢这种点选式操作，省去了记标记的负担。

但我要提醒一句：可视化工具只是把标记变成了按钮，底层逻辑还是那两边内容。如果不理解 Current 和 Incoming 分别代表什么，很容易点错。我见过实习生把所有冲突都点了 Accept Current，结果把同事写的整个功能模块吞掉了。所以我建议新手前几次冲突尽量用纯文本方式手动解决，等你彻底搞懂了标记含义之后，再回到工具里用按钮，那时候你会觉得可视化界面只是加速器，而不是黑盒。

4. 踩过的坑：常见问题与排查技巧实录

4.1 陷阱一：把标记删除当成解决冲突

这是我见过最典型的新手错误：打开冲突文件，发现标记碍眼，于是用编辑器替换功能把所有<<<<<<<、=======、>>>>>>>全删了，以为这样冲突就解决了。但这样做之后，代码可能变成两段内容首尾糊在一起，语法直接报错，或者逻辑上出现重复定义。我之前带过的一个新人就是这么干的，他把一个包含return语句的冲突块两边内容都留下来了，函数执行完第一段直接返回，第二段永远到不了，导致线上一个接口数据缺失，排查了整整一下午。

正确的做法永远是：先理解两边内容，再决定保留哪部分。如果你担心自己会删错，可以在动手前先复制一份原始文件备份，或者用git diff把冲突前后的状态看得更清楚。处理完后别忘了运行项目测试或编译，确认代码行为符合预期。这个步骤看起来简单，但能挡住九成低级事故。

4.2 陷阱二：无脑选择一方，导致功能丢失

另一个高发问题就是"无脑保留自己这边"。有些开发者在冲突时天然倾向于相信最新拉下来的代码就是对的，或者反过来觉得别人的分支比较高级，于是所有冲突都选 theirs。结果就是某一边的改动被整体丢弃，而且因为 Git 把这次合并记录成了正常提交，你甚至很难在 diff 里快速察觉哪部分丢了。

尤其是配置类文件、数据库迁移脚本、接口协议定义这类内容，往往是你改了字段 A，同事改了字段 B，两边都有价值。遇到这种冲突，我最常做的动作是把两个版本都复制到临时文件里对比，然后逐字段合并。实在拿不准的时候，直接去问改这段代码的人："这个配置你是想改成什么？我们俩的改动要同时保留吗？"沟通的成本永远低于上线后排查问题的成本。

4.3 陷阱三：忘记 add 或提交了仍然带标记的文件

解决完冲突但没执行git add就去 commit，会看到 Git 报错，这个错误往往醒目，倒不会造成严重后果。更隐蔽的问题是：你以为把所有冲突都处理了，其实遗漏了一小段标记，然后直接git add .提交成功。因为 Git 不会检查你的文件里还有没有<<<<<<<，它只认你有没有把文件放入暂存区。所以提交之前，我强烈建议执行一次：

$ git diff --check

这个命令会扫描暂存区和工作区的差异，专门检测冲突标记和空白错误。如果输出为空，说明没有残留冲突标记，可以放心提交。养成这个习惯之后，我几乎再也没有把标记带进过提交历史。

4.4 陷阱四：rebase 过程中连续冲突，心态直接崩

前面我讲的都是 merge 冲突，但在git pull --rebase或者手动执行git rebase时，冲突体验会更折磨人。merge 是把两个分支的内容合并成一个提交，冲突通常一次出来；rebase 则是把你当前分支的每个提交，逐个重新应用到目标分支之上，假设你有 5 个提交，每个提交都可能在某处冲突，于是你会连续经历 5 次"改文件、add、continue"的循环。很多时候新人处理完第 3 个就已经想摔键盘了。

而且 rebase 冲突中 HEAD 的含义和 merge 不完全一样。在 rebase 过程中，HEAD 并不总指向你原来的分支顶端，而是指向正在被重放的提交的父提交，这会让理解冲突内容变得更困难。我的建议是：如果你还是 Git 新手，遇到 rebase 冲突较多的时候，不要硬刚。先执行git rebase --abort退回 rebase 之前的状态，然后改用git merge完成合并，保住代码再说。等你对冲突标记的感知足够敏锐了，再考虑要不要追求 rebase 带来的线性历史。

4.5 如何有效减少冲突：一些团队协作习惯

冲突虽然正常，但太频繁也会消耗团队精力。我见过一个团队，几乎每天都有同事因为冲突在这疯狂喊人帮忙。后来我们改了几条习惯，冲突频率明显下降。第一，控制分支的生命周期，小步开发、勤往主干合并，分支放太久，主干不断前进，两边差异越来越大，冲突几乎不可避免。第二，少动公共文件和全局配置，如果一定要改，先在群里说一声，让大家有心理准备。第三，经常把主干的更新拉回到自己的分支，不要等着最后一刻合并，越早同步，合并时冲突区域就越小。第四，统一代码格式化工具和行尾符设置，Windows 和 macOS 的 CRLF/LF 差异会让 Git 产生大量"幽灵冲突"，看似没改什么却疯狂冲突，给项目根目录加上.gitattributes统一换行符能解决很大一部分问题。

5. 从崩溃到平常心：我的一点个人体会

5.1 心态转变：冲突不是世界末日

我做了这么多年开发，处理过的冲突大概上百次，慢慢有一个很深的感受：看到<<<<<<< HEAD时的反应，从最初的慌乱到现在的平静，本质上不是因为我的 Git 命令记得更熟了，而是因为我已经明白，冲突不是一种惩罚，它是并行工作的必然产物。两个人都用心改了同一个文件，才会出现冲突；这恰恰说明大家在同一个项目里都做了实事，而不是各自摆烂。所以下次再遇到冲突，不用急着怀疑自己，更不用产生负罪感。它只是一个待办事项，处理完提交，合入功能，一切照常。

5.2 冲突是一份免费的代码审查

如果你愿意换个角度看，每次冲突其实都是一次"被迫"深入阅读别人代码的机会。有一次我处理一个公共工具函数的冲突时，发现同事把整个错误处理逻辑重写得更健壮了，比我原来的版本好太多。当时我差点习惯性选了自己的 HEAD 版本，幸好多看了一眼那几行代码，最后保留了他的实现，还顺手把我的调用逻辑适配了上去。那次经历让我意识到，冲突标记后的另一段代码，可能是别人花心思写出来的优化，不要本能地把它当成"入侵者"。抱着这种心态去解决冲突，你收获的不仅仅是代码的合并，更是对项目全貌更清晰的理解。下一次，当那串熟悉的尖括号再次出现在你面前，记得从容地打开它，慢慢做选择。