如果你第一次在代码里看到 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 从看见尖括号到提交建议按这个节奏走完整处理流程我推荐新人按顺序执行先git status把所有提示“both modified”的文件抄下来。打开第一个冲突文件搜索。对每一处冲突阅读上下两段内容判断是“保留当前分支”“保留合并分支”“两边都改”还是“重写这一段”。修改后删除所有、、标记。存盘后执行git add 文件告诉 Git“这个冲突我处理完了”。所有文件处理完如果之前是 merge执行git merge --continue如果是 rebase执行git rebase --continue如果没这个命令流程直接git commit。提交完成后跑一下目标分支的测试尤其是冲突区域。用 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 还有个吊命神器就是 refloggit 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_emailexample.com cat ~/.ssh/id_ed25519.pub把输出的公钥串复制进平台设置的 SSH 公钥栏目即可。这一步配好了后面使用会顺滑很多。很多新手对 Git 无比恐惧其实只是因为远程托管平台的钥匙没配好每次都要输密码或收到权限报错误以为 Git 本身很难。5.5 常见 HEAD 相关报错速查报错或提示含义应对 HEAD当前分支代码与合并分支冲突手动保留或改写删除标记HEAD detached at 3f7a2bf游离 HEAD当前不指向分支需要保留改动就git switch -cfatal: not a git repository当前目录不是 Git 仓库检查是否在仓库内或初始化git push rejected远端有新提交本地没有先git pull或git fetch再处理nothing to commit, working tree clean工作区干净没有任何改动不是报错是“没问题”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 并不是什么高深莫测的东西它就是一个“当前所在位置”。新人崩溃的瞬间多半是第一次见到从未解释过的符号把符号还原成具体含义就没什么可怕的了。
看懂 Git HEAD 与冲突标记，代码合并不再慌
如果你第一次在代码里看到 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 从看见尖括号到提交建议按这个节奏走完整处理流程我推荐新人按顺序执行先git status把所有提示“both modified”的文件抄下来。打开第一个冲突文件搜索。对每一处冲突阅读上下两段内容判断是“保留当前分支”“保留合并分支”“两边都改”还是“重写这一段”。修改后删除所有、、标记。存盘后执行git add 文件告诉 Git“这个冲突我处理完了”。所有文件处理完如果之前是 merge执行git merge --continue如果是 rebase执行git rebase --continue如果没这个命令流程直接git commit。提交完成后跑一下目标分支的测试尤其是冲突区域。用 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 还有个吊命神器就是 refloggit 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_emailexample.com cat ~/.ssh/id_ed25519.pub把输出的公钥串复制进平台设置的 SSH 公钥栏目即可。这一步配好了后面使用会顺滑很多。很多新手对 Git 无比恐惧其实只是因为远程托管平台的钥匙没配好每次都要输密码或收到权限报错误以为 Git 本身很难。5.5 常见 HEAD 相关报错速查报错或提示含义应对 HEAD当前分支代码与合并分支冲突手动保留或改写删除标记HEAD detached at 3f7a2bf游离 HEAD当前不指向分支需要保留改动就git switch -cfatal: not a git repository当前目录不是 Git 仓库检查是否在仓库内或初始化git push rejected远端有新提交本地没有先git pull或git fetch再处理nothing to commit, working tree clean工作区干净没有任何改动不是报错是“没问题”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 并不是什么高深莫测的东西它就是一个“当前所在位置”。新人崩溃的瞬间多半是第一次见到从未解释过的符号把符号还原成具体含义就没什么可怕的了。
