企业官网建设流程全解析

看到一屏的<<<<<<< HEAD，我隔着屏幕都能感受到那种绝望。刚把功能分支合并回主分支，Git 啪地弹出一堆冲突标记，满屏幕的<<<<<<< HEAD、=======、>>>>>>> feature，脑子里只有一个念头：代码怎么变成乱码了？更崩溃的是，根本不敢删这些符号，生怕删掉什么关键内容。这个场景我见过太多次，几乎每个新人都要经历这么一遭。

所以我想把这件事彻底讲清楚：HEAD到底是什么？为什么冲突标记里写的是HEAD？遇到冲突该怎么处理？日常要怎么做才能少遇到这种“满屏符号”的鬼故事。这篇文章不是一本完整的 git 使用教程，默认你已经装好了 Git，如果还没装，先找对应系统的安装教程把环境配好就行。我们要聊的，是装好之后最让人崩溃的那个瞬间。适合刚接触 Git、正在被 merge 和 rebase 折磨的新手，也适合要带新人的老手直接拿去当培训素材。

1. 先搞懂 HEAD 这个指针，冲突标记就不吓人了

1.1 HEAD 是什么：一个可以移动的指针

很多新人看到HEAD就会以为它是一个特殊分支，或者是什么错误提示。其实HEAD在 Git 里只是一个指针，指向当前所在的分支，而分支本身又是一个指针，指向某一次提交。通常的链条是：HEAD -> refs/heads/master -> 最新一次提交。

打个比方：一个 Git 仓库就像一本贴了很多书签的笔记本，每个分支书签都夹在某个时间点的记录上，而HEAD就是你现在正在看的那一页。你切换到哪个分支，HEAD就跟着夹到哪一页。所以你写代码时，所有提交都发生在HEAD指向的位置。

想知道自己在哪里，两个命令足够：git symbolic-ref HEAD会输出类似refs/heads/master的路径，告诉你 HEAD 正指向哪个分支；git log --oneline -1会显示 HEAD 当前指向的最新提交。搞懂这一点，后面冲突标记里的HEAD就很好解释了：它代表冲突发生时，你所在分支那一边的代码。

1.2 为什么冲突标记里的“HEAD”代表当前分支

Git 合并两个分支时，如果同一个文件、同一行的修改在两边不一样，Git 不知道应该保留谁，就会停下来把问题抛给你。发生冲突时，你正处在目标分支，比如要合并 feature 进 master，你会在 master 上执行git merge feature，所以HEAD此时就代表 master。冲突块里<<<<<<< HEAD下面那一段，就是 master 当前的版本；>>>>>>> feature下面那一段，则是 feature 分支的版本。

有人看到HEAD以为 Git 崩溃了，其实它只是在喊：这里有两个人都改了同一行，一个是我的现状（HEAD），一个是你带来的（feature），到底留谁，你来决定。如果合并的是其他分支，>>>>>>>后面会显示那个分支的名字，所以标记并不会永远只叫 feature。理解到这一层，你已经比大多数新人强了。

1.3 detached HEAD 又是怎么回事

和 HEAD 相关的另一个新人崩溃点，是执行git checkout 某个commit的哈希后，终端提示You are in 'detached HEAD' state。翻译成人话就是：你的 HEAD 不再指向任何分支，而是直接指向了一个具体提交。这种状态下如果直接提交，新提交会挂在一个无名分支上，之后切走就很难找到。

解决方法很简单。如果只是临时查看代码，看完切回原分支即可；如果想基于这个提交继续开发，先执行git checkout -b fix-xxx，给它一个分支名，让 HEAD 重新回到分支上。很多教程会警告你在 detached HEAD 里别乱提交，真实原因就是怕提交变成了“孤儿”。你现在知道了原理，就不会再被这句话吓住。

2. 三分钟亲手复现一次 git 冲突，看懂 <<<<<<< HEAD

2.1 用一条命令链复现冲突现场

不要凭空想象冲突长什么样，自己动手造一个出来是最快的。打开终端，随便找个空目录操作：

mkdir git-demo && cd git-demo git init echo "print('hello')" > app.py git add app.py git commit -m "init" git checkout -b feature

然后修改app.py，把内容改成print('hello feature')，提交：

git commit -am "feature change"

切回 master，再把同一行改成print('hello master')，提交：

git checkout master # 编辑 app.py git commit -am "master change"

最后执行git merge feature，你会看到类似这样的输出：

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

此时打开app.py，就是最经典的崩溃现场。整个过程不到三分钟，但你亲手触发了一次真正的冲突，后面再看到标记就不会觉得陌生了。

2.2 冲突标记三件套：<<<<<<<、=======、>>>>>>>

冲突文件里通常长这样：

<<<<<<< HEAD print('hello master') ======= print('hello feature') >>>>>>> feature

三行标记的含义非常重要：<<<<<<< HEAD到=======之间是当前分支，也就是 HEAD 侧的内容；=======到>>>>>>> feature之间是要合并进来的分支的内容；>>>>>>>后面跟着的是传入分支的名字。

解决冲突就是三件事：决定要保留哪一侧、把不要的代码删掉、最后把三行标记也删干净。如果两边内容都有用，就手动拼接，不一定要二选一。这里有个容易踩的坑：冲突可能出现在多个文件、多个位置，千万不要解决完一个文件就以为大功告成，建议在编辑器里全局搜索<<<<<<<，逐个确认。

2.3 两种快速解法和一个必须避开的坑

如果明确只想保留某一侧，可以用命令直接选边。在 merge 冲突的状态下：

• 保留当前分支版本：git checkout --ours app.py
• 保留传入分支版本：git checkout --theirs app.py

这两个命令执行后，文件已经变成对应版本，但不要忘了git add app.py，然后git commit提交合并结果。工具栏里的“接受当前更改/接受传入更改”按钮在背后执行的也是类似操作，只是更直观。

必须避开的坑：--ours和--theirs在git rebase时的含义是反的。因为在 rebase 过程中，你正在把当前分支的提交一个个“搬到”目标分支上，此时 HEAD 侧的身份发生了互换。我见过不止一个新人用反参数，直接把同事代码覆盖成空。所以，如果对语义没把握，老老实实用编辑器手动处理最安全。

处理完所有冲突文件后，执行git status，状态里如果已经不再显示Unmerged paths，就可以提交了。标准流程是git add .，然后git commit，Git 会打开一个预填好合并信息的提交界面，直接保存退出即可。注意如果界面上提示有未合并文件，说明还有东西没 add 干净；宁可在这一步多等十秒，也别急着强推提交。这一步做完，<<<<<<< HEAD才算真正被你从仓库里赶走。

3. 解决冲突后的收尾：amend、worktree 与提交习惯

3.1 git commit --amend：改掉刚刚提交的“后悔药”

很多人搜 git commit --amend怎么使用，其实这个命令并不神秘。它的作用是修改最近一次提交，而不是额外增加一个提交。比如你刚提交完就发现漏了一个文件，或者提交信息写错了，都可以用它补救。

两个高频用法：

# 修改最近一次提交的信息 git commit --amend -m "feat: 修复登录按钮样式" # 补充漏掉的文件，且不修改提交信息 git add . && git commit --amend --no-edit

注意一个关键点：--amend不是原地修改，而是创建一个新的提交对象来替换旧的提交，所以 commit 哈希会变。如果旧提交已经推送到了远端，再去 amend 会导致本地和远端历史分叉，同事下一次 pull 就会看到莫名其妙的多余提交。经验法则很简单：只在提交没有推送出去之前用，推送过的公共提交不要去改，宁可追加一个新提交，把要修补的内容写清楚。

3.2 git worktree：同时开多个分支，减少人为冲突

还有相当一部分冲突不是代码写得对错，而是切换分支时把工作区搞得一团乱。比如你在 A 分支改了一半，被叫去 B 分支修 bug，git checkout时报错说本地有修改未提交，于是你慌慌张张 stash 或强制丢弃，最后两边代码混在一起，合并时就爆炸了。git worktree就是为解决这种问题而生的。

它允许同一个仓库里挂多个工作目录，每个目录对应一个分支，互不干扰。常用命令：

# 把 feature 分支单独开一份到仓库外的目录 git worktree add ../git-demo-feature feature # 查看当前所有 worktree git worktree list # 不需要时移除 git worktree remove ../git-demo-feature

使用体验上，相当于同一份 Git 历史同时打开了几个“独立窗口”。在 A 窗口开发，在 B 窗口修 bug，不用反复 stash 和 checkout，自然减少了把修改带错分支的问题。注意该功能需要 Git 2.15 以上版本，老版本可以先升级。添加 worktree 时目标目录必须不存在或为空，如果已经建了同名文件夹，先删掉或换个路径。

3.3 小步提交 + 频繁同步，让冲突无处可藏

冲突本质上不是怪某个人写了错代码，而是两边的改动在同一处“撞车”了。撞车概率和改动范围、时间跨度直接相关。两个分支各改同一行，拖了两周才发现，几乎必冲突；如果每天同步，很多冲突根本不会发生，因为 Git 能自动合并掉不相干的修改。

我的习惯是：不在一棵大树上做两天以上的开发；每次功能点完成就提交；每天至少执行一次git pull或从主分支合并最新代码；如果 feature 分支周期长，每周把主分支 rebase 过来一次。提交粒度小了，就算真的冲突，定位也很快，因为冲突区域通常很小。这个方法不复杂，但确实帮我省掉了大量紧急救火的场面。

4. 新人高频报错排查：not a git repository、bad tree object、login failed

4.1 fatal: not a git repository 的原因与自救

在终端里执行git status，如果看到fatal: not a git repository (or any of the parent directories): .git，第一反应不是仓库坏了，而是当前目录不在 Git 仓库里。最常见的情况是：shell 当前目录是普通文件夹；或者你从外层进入了一个还没有git init的子目录；又或者上一手把.git目录删了。

排查顺序：先pwd看当前路径，再用git rev-parse --show-toplevel看仓库根目录被 Git 识别成哪里。如果根目录不是你以为的那个，说明你在子目录里；如果命令报同样的错，说明这个目录根本不是仓库。此时要么cd到仓库根目录，要么用git init重新初始化，但不要随便对已有项目 init 两次，否则可能把完整仓库搞成孤儿历史。

4.2 bad tree object：.git 目录受损后的处理与安全提醒

Git 的所有版本信息都保存在.git目录里。如果它内部的对象数据库损坏，比如磁盘问题、复制仓库时漏掉了文件、或者被某进程半途写坏，你会看到fatal: bad tree object之类的报错。通常的抢救流程是：先用git fsck --full检查对象完整性；再用git reflog查看最近操作；如果远端还有一份完整 clone，直接重新 clone 往往比修复更快。

顺手说一个安全习惯：不要在生产服务器、静态托管目录或公开可访问的目录里暴露.git。因为完整仓库里包含每次提交的全部代码和历史，一旦.git目录泄漏，别人可以直接把它下载下来还原源码。部署时应该明确禁止访问该目录，或者构建产物里干脆不携带它。这不是什么高深的安全知识，但很多团队吃过亏。

4.3 login failed 与 SSH 免密配置

用 HTTPS 方式 push 时，经常会遇到Login failed或者 GitLab 类平台提示check api token or GitLab version。原因基本是凭证过期、token 失效，或当前凭据管理器和远端平台版本不匹配。与其每次去更新密码，不如一次性配置好 SSH 免密。

如果还没有密钥，生成一个：

ssh-keygen -t ed25519 -C "you@example.com"

把~/.ssh/id_ed25519.pub的内容添加到代码托管平台的 SSH Keys 设置里，然后测试：ssh -T git@gitee.com或ssh -T git@github.com。看到欢迎信息就说明通了。之后把远端地址换成 SSH 格式，比如git@gitee.com:user/repo.git，重新 clone 或设置 remote，就再也不用输入密码。

顺带一提，Windows 上配置过 SSH 后如果还说 Permission denied，先ssh-add ~/.ssh/id_ed25519把私钥加进 ssh-agent，很多坑都是因为 agent 没加载密钥。

4.4 新人高频报错速查表

5. 三个在 Git 里平稳活下来的实用习惯

5.1 动手之前，先看一眼 git status

很多冲突和误操作，都是因为没看清当前状态就开干。git status只有几行字，但会告诉你三件事：现在在哪个分支、暂存区有什么、有没有未合并的路径。它就像开车前的仪表盘，花不了两秒钟，却能避免你把临时文件、冲突标记一起提交上去。

我见过最荒唐的一次事故：同事在编辑冲突文件时把<<<<<<<和>>>>>>>留在代码里，然后提交推到了远端。只要提交前看一眼 git status 和 git diff，这种低级问题完全不会发生。养成这个习惯以后，你的 Git 操作会稳一大截。

5.2 把提交拆小，把信息写清楚

提交越小，出问题后的定位越容易。“修复登录按钮样式”这样的提交，能让后来的人一眼看懂改动意图；“更新一堆文件”这种提交，一旦出现冲突，别人根本不知道你想干嘛，只能瞎猜。

另外小提交还有额外好处：当某个改动引发 bug 时，可以用git log -S '关键字'或git bisect快速定位到具体提交。如果你的提交粒度太大，二分查找会非常痛苦。这条经验不花成本，长期受益。

5.3 解决冲突前，先给文件留个后路

我第一次手动解冲突时，删标记删得太爽，直接把同事那段代码全删了，还提交了。等到代码评审才被发现，心里只剩崩溃。后来我学乖了：在动冲突文件之前，先复制一份到工作区外，例如cp app.py /tmp/app.py.conflict.bak，或者让 IDE 的本地历史自动留档。万一操作失误，还能翻回去。

还有一个补救手段是git reflog，它记录了 HEAD 在仓库里的移动历史。即使你把文件改到面目全非，也可以从 reflog 找到解决冲突之前的那个 commit，把文件捞回来。掌握 reflog 之后，你会发现自己敢大胆操作了，因为大多数错误都能撤销。

最后分享一个我自己的经验：看到<<<<<<< HEAD的那一刻，真不用慌。它只是 Git 在请你在两个版本之间做个选择，你才是最终拍板的人。第一次解决冲突可能会花二十分钟，第三次也许只要两分钟。喝口水平复一下，从第一个冲突块开始，逐块处理，能用编辑器按钮就用按钮，能用 status 确认就多确认一次。等你真正理解了 HEAD 的含义，再看到满屏标记时，你心里想的只会是：“哦，又来了，行吧，这次留哪边？”