日常开发里，真正让你在 Git 上翻车的，往往不是某个冷门命令不会用，而是那些你天天在敲、自信满满的基础操作，在边界情况下做出的错误假设。我见过不少写了三五年业务的同事，merge 和 rebase 天天用，但被问到"rebase 之后为什么 push 被拒"时哑口无言；也见过有人执行git reset --hard HEAD~1回滚自己代码，结果把同事刚推上来的提交也一并干掉了，一整天都在求爷爷告奶奶恢复数据。所以这套"Git 测验"我没打算考你背了多少命令参数，而是考你对 Git 底层机制的理解深度——提交图怎么走、引用怎么动、工作区和暂存区的关系是什么。你能不看资料独立思考这 10 道题，并说得清每个选项背后的原理，那 Git 水平基本就是中上等了。

这篇文章适合三类人：一是准备面试、想系统查漏补缺的开发者；二是被 Git 坑过几次、想搞清楚"为什么"而不是只会复制粘贴命令的实操派；三是想在团队内部做技术分享或能力摸底的同学。我会先把自测题完整摆出来，建议你拿张纸写下答案再往下看解析，因为后半部分我会逐题拆解原理、还原真实踩坑场景，还附上我踩过之后的恢复手段。直接看答案的话，效果会打不少折扣。

1. 为什么这 10 道题比"命令大全"更能检验 Git 水平

网上 Git 教程多如牛毛，动不动就是"20 个常用命令""45 个 Git 技巧"，但很多人看完就忘、遇到问题还是只会git add .加git commit -m。原因很简单：命令是表，机制是里。你不知道git reset三个模式到底动了哪三棵树（工作区、暂存区、HEAD），就永远记不住什么时候用--soft、什么时候用--hard。这套测验正是冲着"机制理解"去的，每一道题背后都对应一个核心概念，而不是一个单纯的命令记忆点。

我选这 10 道题时遵循了三个标准。第一，都是高频操作，日常开发几乎每周都会碰到；第二，网上说法存在争议或模糊地带，比如"merge 好还是 rebase 好"，这类问题不问清前提就聊结论很容易带偏人；第三，能区分"用过"和"理解"两个层次——会敲命令的人是前者，能把原理讲明白的是后者。

为了让你看清知识覆盖面，我把题目和对应的核心考点列成了一张表：

这些考点不是背了就有用的。我见过一堆人栽在第 4 题上：想回看某个历史版本，git checkout <commit-hash>切过去，发现新写了个提交但找不到了，于是一脸惊恐跑来问怎么恢复。根本原因就是没理解 HEAD 在那种状态下指向的是提交而不是分支，脱离分支的提交像断了线的风筝，默认不会被任何引用持有。这类问题是代码写得多但不思考底层的人最容易踩的坑。

建议你先不看我的解析，把这 10 个场景当作真实发生在你身上的情况，写一写：如果现在遇到这个问题，你的第一步操作是什么？第二步怎么验证？验证不了会怎么排查？写完之后再往下对答案，会发现很多"我以为会用"的操作其实理解是错的。

2. reset 和 revert 的边界：回滚操作的第一道分水岭

先说第 1 题。场景是同事跑过来说"帮我回滚那个提交"，但你首先要追问一句：这个提交已经推到远端、被别人拉走了吗？这是决定用git reset还是git revert的唯一标准。

如果提交只存在于本地，还没推上去，用git reset完全没有问题。它的本质是移动 HEAD 指针，把分支回退到你指定的位置，仿佛那个提交从来没存在过。但如果提交已经推到共享分支，且同事拉下去甚至基于它开发了新代码，此时你再用reset把历史抹掉，灾难就来了：同事下一次git pull时会看到两端历史完全分叉，要么被迫强推，要么历史里出现一堆重复提交，整个团队的提交线团成一锅粥。

所以共享分支上要回滚，git revert才是正解。它能做的不是删除那个提交，而是生成一个"反向提交"，把改动抵消掉。看似多了一个提交记录，但历史是线性向前的，所有基于旧代码的同事都能平滑合并。说白了，reset是"改写历史"，revert是"追加历史"，前者适合私人开发，后者适合公共场合。

然后是第 2 题，这个场景我亲眼见过：某次发版前，组里一位同学想回退自己刚提交的一个小改动，自信地敲了：

git reset --hard HEAD~1

结果发版没回到，反而把另一个同事半小时前刚 push 上来、还没合并进主干的功能提交一起回滚了。原因是那条分支上不止他一个人有提交，HEAD~1指向的是分支上最近的一次提交，而不是"他自己的"最近一次提交。这个错误几乎每周都会在某个团队里上演一次。

好消息是，git reset --hard之后提交并没有真的消失，它们只是从分支引用上"脱落"了，仍然以悬挂对象的形式躺在 Git 对象数据库里，只是默认没有任何引用指向它们。此时全靠git reflog救命。reflog 记录的是 HEAD 指针每一次移动的历史，相当于 Git 的"操作日记"。你可以这样恢复：

git reflog

输出里会列出最近每次 HEAD 变化对应的提交 hash 和操作说明，找到那条写着reset: moving to HEAD~1的记录，它上一行就是你 reset 之前的 HEAD 位置。拿到那个 hash 后执行：

git branch recover-branch <那个hash>

这样就把丢失的提交重新挂到一个新分支上了。实测下来，只要没跑git gc清理悬挂对象，绝大多数"误删提交"都能靠这个流程救回来。

这里有个血泪教训：reset --hard之前，先敲一下git log --oneline -5看清楚当前分支具体形状，最好把当前 HEAD 的 hash 抄下来。别偷懒，这个习惯救过我至少三次命。

3. merge、rebase 与游离 HEAD：提交图视角下的三条真理

第 3、4、5 题其实可以放在一起理解，因为它们全都在讲同一件事：Git 里"引用"和"提交图"之间的关系。

先说第 5 题，merge 和 rebase 的本质区别。很多教程喜欢说"merge 保留历史、rebase 使历史线性"，这句话对，但没讲透机制。git merge会找到两个分支的共同祖先提交，然后把两条线的改动合并，生成一个新的合并提交；git rebase则是把你当前分支上每个提交"摘下来"，依次重放到目标分支的最新提交之上，整个过程会生成全新的提交对象，commit hash 全部改变。一个是搭桥，一个是改写。

什么时候用哪个？我的建议是按共享与否来分。自己本地没推过的功能分支，随便 rebase 保持线性没问题，看提交历史时一行接一行非常清爽。一旦分支推到远端、和别的协作者共用，就别 rebase 了。你重写了历史，别人基于旧历史的新提交全都会对不上号，push 必然被拒，强行推送又可能导致他人本地历史错乱。

第 3 题说的正是这个场景：某同学在本地把 feature 分支 rebase 到了最新 master 上，提交历史变得很漂亮，自信地git push，结果远端报错说 rejected。原因很简单，远端 feature 分支上还留着旧版本的提交，本地 rebase 后生成了新 hash，两边历史毫无共同点，Git 当然拒绝快进合并。解决办法其实是一条团队纪律：只 rebase 自己独有的、尚未推过的提交，一旦推上去，后续同步一律用 merge。

第 4 题是另一个高频事故。执行git checkout <commit-hash>后，你的 HEAD 会进入 detached 状态——它不再指向某个分支，而是直接指向一个具体提交。很多人在这个状态里继续开发、照常 commit，完全没意识到自己创建了一个不属于任何分支的提交。这时如果直接切回原本的分支，这个新提交就会变成孤岛，日志里根本看不到它。

要避免丢失，重复一遍：任何在 detached HEAD 状态下的提交，应该立刻做一次git branch fingertip <hash>或git checkout -b new-branch，让某个引用指向它。如果你已经切走了，也别慌，马上git reflog找到那个提交 hash，然后照样用git branch <名字> <hash>拉回来。这个操作我至少做过六七次，每次都能找回，因为提交对象本身不会凭空消失，只是等一个"引用"来接住它。

4. fetch、stash、clean 等高频小坑的认知刷新

第 6 到 10 题看起来是五件小事，但每件都是日常开发里最容易"顺手一敲就出事"的坑。逐个拆一下。

先看第 6 题，git stash pop报冲突。很多人以为 stash 是"先存起来，稍后一键恢复"，没想到 pop 也是一次合并操作。如果你 stash 之后又在同一文件的同一区域做了改动，pop 时 Git 就会因内容冲突而失败，输出一堆 CONFLICT 信息，stash 里的内容不会被清除。此时正确的处理顺序是：先手动编辑冲突文件，解决后用git stash drop删除这条 stash 记录，而不是慌慌张张地反复 pop。另外特别提醒，git stash pop冲突时 stash 对象会保留，方便你来回调数据；相比之下git stash apply只应用不删除，更适合需要多次复用的场景。搞清楚这个小区别，能少死不少脑细胞。

第 7 题是关于.gitignore的经典困惑：明明写了config.ini，git status却还显示这个文件。原因九成是文件在添加到.gitignore之前就已经被git add追踪了。.gitignore只对未被追踪的文件生效，对已经进入暂存区或历史版本的文件没有任何约束力。解决方法是先把文件从索引中移除：

git rm --cached config.ini

然后重新提交，之后.gitignore才会真正起作用。这块要注意的是，我见过有人直接在.gitignore里加了一堆*.log，结果发现之前提交的日志文件还在仓库里，误以为配置没生效，实际上是追踪状态没解除。碰到这类问题，先跑git ls-files看文件是否真的被追踪，比反复改规则效率高得多。

第 8 题，git commit --amend后 push 失败，本质上和第 3 题同源。--amend会改写最近一次提交的 hash，所以同样属于"重写已发布历史"。如果这个提交只有你一个人在本地，问题上一次就没改完想并进上一条，那没问题；但如果你已经 push 过了，别人 pull 过，这时 amend 再 push 必然被拒。正确姿势是：未推送的提交随便 amend，已推送的提交用git revert产生新提交来修改，或者提前沟通好让所有人接受强制推送的代价。

第 9 题比较简单，但很多人一开始都懵：git fetch把远端提交拉回本地，为什么git log没看到？因为 fetch 只更新了远程跟踪分支origin/xxx，并没有动你当前分支的任何内容，也不会合并到工作区。换句话说，fetch 只是把数据"搬到了家门口"，pull 才是 fetch 加 merge 两步走。所以想看远端最新提交，应该git log origin/master或者直接用git pull。这题考的是对"本地分支、远程跟踪分支、远端分支"三者的区分，基础不牢的人容易把 fetch 当成"已更新"。

第 10 题，git clean -fd。这个命令会永久删除当前工作目录下所有未被追踪的文件和文件夹，注意是"永久"，不会进入回收站，也不在 reflog 的救援范围内。-f是强制，-d是包括目录。我见过有同学想清理构建产物，一激动敲了git clean -fd，结果把自己笔记本上积累了几个月的乱七八糟文件全删了，连哭都来不及。如果你只是想删掉调试用的临时文件，先跑git clean -nd看一下实际会被删除的清单，确认无误再去掉-n执行。另外-x参数连被 ignore 的文件也不会放过，危险系数更高，新手别在同一个命令里乱叠参数。

5. 组内测验复盘：答错率最高的位置暴露了什么

这套题我在团队里实测过一次，让 6 名组员闭卷作答，结果挺有意思。第 2 题（reset 误删他人提交）和第 4 题（detached HEAD 丢提交）答错率最高，各有 4 人选择了"完全不知道该怎么办"；第 3 题和第 8 题（历史改写后 push 被拒）有 3 人能说出来"历史变了"这个原因，但具体怎么解决就语焉不详了。答得最好的是第 9 题，6 个人都知道 fetch 和 pull 的区别，看来基础命令的普及度确实不低。

复盘下来，我注意到一个规律：答错率高不是因为大家笨，而是因为日常工作里基本不会主动制造这类事故，自然也没机会积累处理经验。大部分人的 Git 知识来源于"遇到问题搜答案"，而不是"先构建心智模型再遇事推导"。比如知道git reset --hard能回滚的人很多，但能在执行前想到"这个操作会改变引用指向、可能让别人的提交悬挂"的人极少。

基于这个观察，我给团队做了一次机制普及，方法也很简单：在白板上画了三棵树（工作区、暂存区、HEAD）和一条提交链，把 reset、checkout、revert、stash 这些操作全部映射成"树的动作"和"引用的动作"。画完一遍之后，之前容易混淆的概念基本都通了。这也侧面印证了测验本身的价值——它不只是一套题，而是暴露盲区的探照灯。

从那次之后，我养成了一个习惯：每次至少要能不看文档写出git reflog和git reset --hard的恢复链路，并且在代码评审间歇，花两分钟给新人模拟一次"事故现场"。Git 这种东西，光看教程永远不如亲手把分支搞坏一次再救回来来得深刻。你现在拿着这套题，找几个真实仓库试一下 reset 和 rebase 的边界操作，相信我，比你看二十篇教程都管用。