企业官网建设流程全解析

如果你第一次在代码里看到<<<<<<< HEAD这种符号，我猜你已经把那几行代码来回看了十分钟，心里全是问号。带我的老开发最怕的就是新人合并完分支后对着屏幕瑟瑟发抖，把有冲突的文件当成了敌人。今天想用一篇能救急的文章，把这些关于 Git、HEAD 和冲突标记的来龙去脉讲透。你不需要一开始就记全部命令，只需要先搞明白一件事：Git 不是想让你难堪，它是把代码合并时自己拿不准的地方原封不动交给你拍板。看懂HEAD，就是看懂 Git 的第一把钥匙。

1. HEAD到底是谁，为什么 Git 输出里到处都有它

1.1 HEAD不是一个神秘单词，它只是“当前分支指针”

很多人记不清HEAD的含义，直觉上翻译成“头文件的头”。在 Git 里，HEAD 是很轻量但极其关键的引用（reference），它表示“你现在贴在哪个提交上”。你敲的绝大多数命令，本质都是围绕 HEAD 在打转：git log默认从 HEAD 开始排；git diff默认对比 HEAD 和工作区；git commit将新提交挂在 HEAD 所在位置。只要理解 HEAD，就理解了一大半的 Git 状态。

具体到仓库内部，HEAD平时并不是一个直接指向 commit id 的文件内容，而是一行“指针的指针”。打开.git/HEAD，你通常看到：

ref: refs/heads/main

意思是：去refs/heads/main这个分支引用里找到真正的 commit hash。分支文件名是 main 还是 master，取决于你初始化 Git 时的默认配置。这层间接关系会带来一个很重要的结论：分支并不是某种抽象的“代码版本”，它只是一个指向提交的标签；HEAD 则是“当前正在使用的那个标签”。

你可以在任何不确定的时候用一行命令验证当前提交：

git rev-parse HEAD

它会输出冗长的 40 位 hash。这串值才是你当前位置的身份证。整篇文章后面提到的<<<<<<< HEAD，里的 HEAD 就是指“你当前分支所指向的那一版代码”。

1.2 HEAD的“附加”和“游离”两种形态

常规使用中，HEAD 指向一个分支名，这叫 attached HEAD。在这种状态下，你git commit之后分支名会跟着往前滚，HEAD 也跟着刷新指向新的提交。但当你直接git checkout 某个 commit hash 或 tag时，HEAD 不再指向任何分支名，直接附着在某个快照上，这叫 detached HEAD。很多新人一看到You are in 'detached HEAD' state就慌神，害怕丢代码。它并没有那么可怕，但也不是可以随手乱改的状态，我后面会专门讲。

1.3 快速搞懂 HEAD~、HEAD^ 和 HEAD@{1}

命令行里还有一堆 HEAD 亲戚，对新人最容易混淆：

• HEAD~和HEAD~2：向上追溯第 1 个、第 2 个提交，表示“历史往前第 n 步”，只看第一父提交。说“上一版”“上上版”用它非常直觉。
• HEAD^：表示“父提交”的简写。对一般单父提交，HEAD^和HEAD~基本等价。但遇到合并提交有多个父提交时，HEAD^2表示合并提交的第二父提交，也就是被合并进来的那个分支尖端。
• HEAD@{1}：不是往上追溯提交，而是回看 HEAD 过去移动的历史，指第 1 次“从前的位置”。它依赖 reflog，后面找回丢失提交时会很强劲。

这四五个符号懂了，你至少能读懂 Git 输出的八成信息，不再看到就蒙。

2. 看到<<<<<<< HEAD的那一刻，到底发生了什么

2.1 冲突标记不是威胁，是一个三方会话记录

我在带新人的时候常说，Git 到不了你的代码，也没能力替你选择哪一行才是正确答案，它唯一能做的就是把这堆矛盾摊开给你看。<<<<<<< HEAD那一串尖括号就是“矛盾摊开”的现场。

假设当前分支 main 上已提交了一行，同事的 feature/login 分支在同一位置写了自己的版本。你执行git merge feature/login后，Git 发现两边都有改、无法自动取舍，就在文件里标出来：

<<<<<<< HEAD console.log("本地分支的版本"); ======= console.log("功能分支的版本"); >>>>>>> feature/login

拆开看：

• <<<<<<< HEAD：上面这段是当前分支的内容，也就是 HEAD 指向的一版。
• =======：分割线，代表上下版本的边界。
• >>>>>>> feature/login：下面这段是合并进来的分支的内容。

所以这个文件打开时其实是“我当前分支 vs 对方分支”的双人对峙录像。你要做的不是把整段删除，而是在两段之间决定留哪个、改哪个，或者合并成一个新版本，最后把所有尖括号、等号行删除干净。

2.2 哪些操作会压出这些尖括号

不只是 merge 会触发。凡是 Git 需要把两边的改动叠在一起的时候，都可能制造冲突：

• git merge合并分支时，双方修改了同一文件的同一区域。
• git pull拉远端更新时，本地和远端都产生了提交且改了同一处。
• git rebase把当前分支提交逐个重放到目标分支之上时，重放某个提交时也会冲突。
• git cherry-pick挑选其他分支提交时，补丁区域和当前内容不一样。
• git stash pop恢复暂存内容时，工作区已有改动，代码对不上。

记住这条规律：只要发生“两边都改且改在同一个位置”，Git 都会纠结。一个新人的崩溃时刻往往发生在没有心理预期的情况下。如果想降低恐惧，先训练自己在任何合并前用git status看一眼“哪些文件 both modified”，这样至少知道冲突数量和位置。

2.3 新人最容易犯的错：把冲突标记当“代码”删了

踩坑现场一：有人看到<<<<<<< HEAD，以为是 Git 留下的垃圾，把一串尖括号直接删除。结果冲突区域的代码一行没动，提交后把对方代码全丢了。

踩坑现场二：有人不想看代码，直接执行git merge --abort把整个合并撤销，然后反复 merge 反复 abort，因为根本不敢面对冲突文件。

踩坑现场三：有人把两边代码胡乱拼在一起，没跑测试就提交，导致编译失败。

正确的心态是把冲突看成一次代码评审：你现在有机会逐行核对两个版本哪边更适合保留。这不是 Git 在惩罚你，而是 Git 在保护你，避免它替你乱决定。

3. detached HEAD 出现时，不慌的第一步

3.1 为什么明明只是看了一眼版本，Git 却说“头游离了”

操作一个仓库时，如果直接git checkout 3f7a2bf，终端往往会输出一大段英文，里面挂着You are in 'detached HEAD' state，后面还提醒你可以再 checkout 其他位置。这段话翻译过来就是：你现在这个 HEAD 没有贴在任何分支名上，像一个没人认领的游标。直接 checkout 一个 commit id 或 tag 是合法操作，常用于临时查看旧版本代码、为了某个历史提交去编译测试。

问题在于，这个状态是“一次性”的。如果你不新建分支就git commit，新提交同样不悬挂在任何分支上，你切回 main 之后，它就变成了孤儿提交。下次git log可能看不到它，新人就会以为代码“丢了”。

3.2 两个保命操作：把游离的提交拉回分支，或者用 reflog 找回

在 detached HEAD 状态下，最容易避免损失的命令非常短：

git switch -c rescue-branch

这条命令从当前已处于的提交新建一个分支，并把 HEAD 挪到新分支上。执行完，你刚才所有改动都有了归属，随便切回哪个分支都不会丢。

如果你已经在 detached 状态下提交过，但没建分支就切走了，别慌，reflog 依然记得。老版本 Git 的这个超能力在事故现场最明显：

git reflog

输出的一列记录中，每条前面有类似HEAD@{3}的编号，记录了 HEAD 之前到底到过哪些位置。你找到刚才那个提交的 hash，执行：

git checkout -b recover-branch <commit-hash>

就能把遗失的提交重新接到一条新的分支上。这是我在无数事故现场救人时最常用的一招，亲测有效。

3.3 什么情况下可以放心留在 detached HEAD

不是所有 detached 状态都要马上“修复”。如果你只是想看看旧版本的代码、验证某个历史版本有没有 bug、跑一下测试框架，那么在这种状态下读完就跑也没问题。只要记住：切走之前没有产生需要保留的新提交，就不会造成实质损失。真正要避免的是：在游离状态下进行了大量创意工作，却还抱着“先切回主分支，过两天再说”的侥幸心理。

4. 遇到冲突后，一套能照抄的处置流程

4.1 从看见尖括号到提交，建议按这个节奏走

完整处理流程，我推荐新人按顺序执行：

1. 先git status，把所有提示“both modified”的文件抄下来。
2. 打开第一个冲突文件，搜索<<<<<<<。
3. 对每一处冲突，阅读上下两段内容，判断是“保留当前分支”“保留合并分支”“两边都改”还是“重写这一段”。
4. 修改后删除所有<<<<<<<、=======、>>>>>>>标记。
5. 存盘后执行git add <文件>，告诉 Git“这个冲突我处理完了”。
6. 所有文件处理完，如果之前是 merge，执行git merge --continue；如果是 rebase，执行git rebase --continue；如果没这个命令流程，直接git commit。
7. 提交完成后跑一下目标分支的测试，尤其是冲突区域。

用 VS Code、IDEA 这类编辑器时，打开冲突文件往往会有“Accept Current Change”“Accept Incoming Change”“Accept Both”按钮。按钮只能作为偷懒入口，更推荐按区域仔细看，因为按钮处理多文件冲突时容易盲目全留。

4.2 --ours 和 --theirs 容易搞反，建议先画草图

有些老开发喜欢用命令直接把冲突文件选边：

git checkout --ours -- src/App.js git checkout --theirs -- src/App.js

如果你不了解方向，稍不留神就选反。merge 场景下，ours 指“当前所在分支”，theirs 指“被合并进来的分支”。rebase 场景则刚好相反，因为 rebase 时当前分支的提交被重新派发到目标分支上，ours 反而代表被你正在处理的那个提交侧。我常用的笨办法是：执行前先git branch --show-current确认当前所在分支，再决定方向。

这种选边只适合“整个文件我只要一边”的场景。如果冲突区域分散，两边各有价值，手动编辑更稳妥。

4.3 提前把冲突量压下来

新人对冲突的恐惧，很大程度来自“一次合并涌出几百个冲突”的绝望感。你没法完全杜绝冲突，但可以明显降低：

• 尽量小步提交，别攒三天临时乱改才推。
• 每次开始新任务前先把主干最新代码合回来或 rebase 到最新，减少差异积累。
• 保持代码粒度小，避免超大文件或多个分支同时改同一块。
• 多人共用一个公共配置或公共 API 文件时，合并前先互相认领。

压缩冲突数量比学会解决冲突更重要。冲突越少，心态越稳。

5. 新人在 Git 里最容易崩溃的另外几个瞬间

5.1fatal: not a git repository不是你删了仓库

这条红字大多数时候不是仓库坏了，而是你站错了地方。Git 本身不会去未初始化的目录执行命令。如果你在一个普通文件夹敲git status，自然提示“这不是仓库”。如果你确定这个目录在某个 Git 仓库内，但提示仍然出现，依次往上cd ..重新执行，直到找到.git目录真正存在的位置。另外，有些人误在.git目录内部执行命令，也会导致这种提示，因为.git不是代码仓库，是仓库的“数据库”。

5.2 动不动就用 reset --hard，丢了提交再喊救命

git reset --hard确实能干脆利落地把工作区、暂存区、HEAD 一起回退到指定提交，但风险是：它默认不保留被丢掉的提交。假如你 reset 之后才意识到某次新提交还没合并，别绝望，Git 还有个吊命神器就是 reflog：

git reflog git reset --hard HEAD@{2}

reflog 会记录 HEAD 每一次移动，通常保留 30 天。所以“硬重置”不是世界末日，但以后还是尽量先用不带--hard的git reset，看清楚了再决定。我自己的习惯是：重要分支上的残留提交，先git branch backup打个备份标签，再用 reset。

5.3 commit 写错了或者漏提交，用 --amend 救场

git commit --amend是新人需要立刻学会的命令之一。它看起来是“修改最后一次提交”，实际是创建一个覆盖原提交的新提交，并把原提交从当前分支移除。适合的场景：

• 刚提交完发现少加了一个文件，或者提交信息写错字。
• 想临时修改最后一次提交，不用为了这几个字再造一个“修改 typo”的提交。

操作顺序：

git add 漏掉的文件 git commit --amend -m "我重写一条清晰的信息"

但要记住两条规则：一是它只适合“还没 push 到公共远端”的提交；如果提交已经推出去且别人也拉了，再 amend 会导致历史分叉，别人 pull 时会看到奇怪冲突。二是 amend 不等于万金油，如果希望完整保留多次提交之间的记录，应该用git rebase -i去整理。

5.4 安装与配置：先修好“地基”

一些新人第一次崩溃其实在源头：Git 还没安装好、user.name 和 user.email 没配置，导致第一次 commit 报错。无论你是 Windows、macOS 还是 Linux，安装后第一件事是配置三要素：

git config --global user.name "你的名字" git config --global user.email "你的邮箱" git config --global init.defaultBranch main

在使用国内远程托管平台时，还需要把本机生成的 SSH 公钥放到账号里，之后 clone、push、pull 才不用每次输密码：

ssh-keygen -t ed25519 -C "your_email@example.com" cat ~/.ssh/id_ed25519.pub

把输出的公钥串复制进平台设置的 SSH 公钥栏目即可。这一步配好了，后面使用会顺滑很多。很多新手对 Git 无比恐惧，其实只是因为远程托管平台的钥匙没配好，每次都要输密码或收到权限报错，误以为 Git 本身很难。

5.5 常见 HEAD 相关报错速查

6. 崩溃解决后的新认知

6.1 Git 世界里没有“丢失”，只有“不在当前视角”

经历过几次冲突和误操作后，我越来越觉得新人崩溃的根源不是 Git 太复杂，而是把 Git 的报错当成了“责备”。<<<<<<< HEAD不骂你，只是把矛盾摆出来；detached HEAD 不谴责你，只是告诉你“当前指针不挂分支”；git reset --hard之后 reflog 默默留下了退路。Git 的真正核心是一张提交图，所有引用，包括分支名、标签、HEAD，都不带情绪，它们只是在图上标注位置。

以后看到任何长满尖括号的文件，先深呼吸，再打开git status，接着按上面第 4 节的流程走一遍。头三次可能会耗十来分钟，到第五次你会发现自己已经能边看 diff 边写注释了。

6.2 给新人的一个实在建议：造一个练习场

别在真实需求仓库里学习 HEAD 的各种状态，风险太大。建议建一个练习仓库：

mkdir git-practice && cd git-practice git init echo "第一行" > file.txt git add . && git commit -m "init" git checkout -b experiment echo "第二行" >> file.txt git commit -am "modify by experiment" git switch main echo "不同第二行" >> file.txt git commit -am "modify by main" git merge experiment

你会立刻得到一个真实的<<<<<<< HEAD冲突，然后按流程解决。整个过程发生在本地练习仓库，随意折腾，不用担心影响同事。我用这个方法带过几个崩溃边缘的新人，成功率很高，因为他们终于能从“被 Git 吓住”变成“亲手制造一次冲突再亲手解决”。

6.3 最后分享一个小习惯

我自己每次提交前会习惯性看一眼git status --short和git diff --stat，它们分别告诉我“哪些文件要进提交”和“这次改动波及多大”。合入分支遇到冲突时，把git diff HEAD HEAD~1这种小范围对比当成日常工具，你会发现 HEAD 并不是什么高深莫测的东西，它就是一个“当前所在位置”。新人崩溃的瞬间，多半是第一次见到从未解释过的符号；把符号还原成具体含义，就没什么可怕的了。