1. 为什么我建议每个开发者都做一次 Git 测验1.1 简历上的“熟练”往往经不住追问Git 学到什么程度才算真的会了我见过不少写了几年代码的人遇到需要回滚一个 commit、把多个提交整理成一个、或者挽救一次误删的分支时依然会手忙脚乱。Git 掌握得好不好靠嘴说不算数拿一套有代表性的 Git 测验做一遍短板立刻现形。这篇文章不写那种假大空的理论总结直接把我平时用来筛选候选人和自测的一套 Git 测验题目拆开讲覆盖基础命令、分支合并、远程协作和灾难恢复每道题都带输出样例和踩坑记录。无论你刚接触 Git 还是已经用了好几年这套题都能帮你把知识体系里的漏洞找出来。先聊个现象我在帮团队招人时十个候选人里有七个会在简历上写“熟练使用 Git”。真到了白板环节问一句“如果改错了文件想回到修改前的状态你会怎么做”能在一分钟内给出准确命令的人很少。有人会答git checkout .有人会答git reset --hard但说不清两者区别。这其实不怪他们很多人的 Git 知识是“点鼠标”学来的图形界面隐藏了底层细节一旦脱离 IDE 就抓瞎。Git 是每个开发者的基本功但基本功恰恰最容易被忽略。日常用到的不过是 clone、add、commit、push、pull 这几个命令碰到分支冲突、误删提交、历史整理这类问题很多人靠搜索引擎临时拼凑拼完了还不一定理解。所以我觉得与其看教程刷视频不如真正地把一套有代表性的 Git 测验认真做一遍。做题的过程就是一次系统性的知识审计能精确告诉你哪块扎实、哪块模糊、哪块完全空白。1.2 一套好测验的价值暴露盲区而不是考倒你一套好的测验不是出一道道偏难怪题来炫技而是围绕真实工作流设计题目覆盖你每天都会用、但可能理解不深的核心操作。比如分支切换时工作区变更怎么处理、rebase 和 merge 的差异、push 被拒绝后怎么安全同步、误 reset 后怎么找回提交。这些场景看起来简单但真正遇到时很多人会因为细节不清导致操作失误甚至把仓库历史搞坏。我常把 Git 测验比作体检做之前你可能自我感觉良好做完之后看到报告上的红色指标才知道该补哪里。而且测验还有一个好处——它逼你输出。阅读别人写的命令时感觉“我会了”但合上教程自己默写一遍你会发现能准确回忆出来的只有不到一半。所以这篇文章里的每一道题我都建议你打开终端在临时目录里亲手敲一遍。哪怕答错了也没关系踩过坑印象才深。2. 这套 Git 测验的出题思路与评分标准2.1 四个考查维度操作、理解、应变、恢复我设计这套测验时刻意绕开了“背诵参数表”的路线因为参数可以查但操作背后的模型必须理解。四个维度分别是基础操作初始化、暂存、提交、查看状态这些是每天都要用的动作考查是否清楚命令产生的实际效果。分支与合并创建分支、切换、merge、rebase、解决冲突考查对提交图结构的理解。远程协作clone、fetch、pull、push、远程分支跟踪考查多人协作时如何处理不同步。撤销与恢复checkout、reset、revert、reflog、clean考查误操作之后的应急能力。这四块基本覆盖了一个开发者的日常全部。如果某个维度得分明显偏低说明你平时在那类场景里依赖了某种“固定动作”但没有真正理解背后的原理。比如有人每次冲突都靠 IDE 按钮点“接受当前/接受传入”真让他手动编辑冲突文件时连标记都不知道代表什么。这就是典型的理解缺失。2.2 题目分层从必会到进阶题目总共分为三个层级层级定位涉及内容L1 必会初级开发者必须具备add/commit/status/log、分支创建切换、简单 pull/pushL2 应会独立完成开发任务merge/rebase、冲突解决、stash、amend、resetL3 进阶处理复杂事故与历史整理reflog 恢复、cherry-pick、rebase -i、clean建议你先从 L1 开始如果 L1 都要想半天说明基础不牢先别急着追求高级技巧。如果 L1、L2 都能快速给出答案再去挑战 L3。这套测验的目的不是比谁命令背得多而是帮助你找到自己真正薄弱的地方从而有针对性地训练。2.3 评分参考我给不同团队用这套测验时一般按“回答速度准确性”综合打分。每个题目我先看答案对不对再看能否解释为什么。比如有人说“撤销最近一次提交用git revert HEAD”这个答案本身没错但如果问他“revert 和 reset 的区别”答不上来我最多给一半分。因为只记住命令不叫掌握知道命令在什么场景下用、会产生什么副作用才算理解。评分时可以把每道题拆成“命令正确性”“参数合理性”“风险意识”三部分。比如回答“丢弃本地修改”时只写了git reset --hard没有提醒这会全部丢失无法找回风险意识就要扣分。下面的核心题目我会把答案和补充说明一起讲方便你自己测评。3. 核心题目与答案详解按场景一步步拆开3.1 基础篇初始化、提交、查看历史题目一在当前目录初始化一个 Git 仓库并要求所有.log文件不被提交。操作步骤git init echo *.log .gitignore git add . git commit -m init project这里的关键点有两个初始化仓库后.gitignore文件本身要提交否则换一台机器后忽略规则就丢了。另外.gitignore里写了*.log以后所有.log文件都会被 Git 忽略不会出现在git status的未跟踪列表中。有人喜欢随手git add .如果项目里没有.gitignore很容易把node_modules、build目录一并传进仓库这是新手最常见的错误之一。所以这道题表面上考初始化实际上是在考你对忽略规则的理解。题目二git status中显示三类文件变更未跟踪、已修改未暂存、已暂存。请说明各自的含义。未跟踪指的是 Git 还不知道这个文件的存在通常是因为它是新建的还没有执行过add。已修改未暂存指的是 Git 已经跟踪了这个文件但工作区内容与暂存区不一致这类改动如果没有add不会进入下一次提交。已暂存表示内容已经写进暂存区执行commit时会包含进去。很多 IDE 的提交面板把这几个状态混在一起显示导致初学者误以为“保存了就是提交了”。搞不清这三个状态就很难理解为什么commit之后文件还显示有改动。题目三想撤销最近一次提交但保留所有改动到工作区用哪条命令git reset --soft HEAD~1--soft会把 HEAD 指向上一个提交同时索引和工作区都保持不变也就是说那些改动还处于“已暂存”状态。如果改用git reset HEAD~1默认--mixed改动会保留在工作区但索引区被重置需要重新add。如果用了--hard那就直接把所有改动都丢掉了所以在不确定时不要轻易用--hard。这道题考的是 reset 的三种模式属于必会内容。3.2 分支与合并切换、合并、rebase题目四当前在dev分支想把main分支的最新提交整合进来你会用 merge 还是 rebase为什么这题没有标准答案取决于你对历史整洁度的需求。git merge main会生成一个额外的合并提交能保留两条分支真实的交汇关系git rebase main会把当前分支的提交依次重放到main之上历史变成一条直线但需要重写提交哈希。如果dev已经推送到远程并且别人也在用rebase会带来麻烦。所以我的建议是本地分支、还没推送、想保持干净历史用 rebase公共分支、需要保留时间线证据用 merge。回答这题时能不能把背后的风险讲清楚是评判关键。题目五合并时出现冲突如何处理并完成合并出现冲突后git status会列出both modified的文件。打开这些文件你会看到类似 HEAD 这是自己的改动 这是来自被合并分支的改动 feature手动编辑这些区域保留想要的代码然后删除、、这三行标记。接着git add这些文件最后执行git commit完成合并。如果是rebase过程中出现冲突解决并add之后执行的是git rebase --continue而不是直接 commit。很多人在这一步习惯性敲git commit结果进入一个奇怪的中间状态所以我经常提醒团队先确认自己在 merge 还是 rebase 中再选择对应的收尾命令。题目六已经推送到远程的提交发现提交信息写错了如何修改如果只有最后一次且远程没有其他人基于它开发可以git commit --amend -m 新的提交信息 git push --force-with-lease--force-with-lease是比git push --force安全得多的做法推送前会检查远程分支是否还是你上次 fetch 时的状态如果有人在你之后推送过操作会被拒绝避免覆盖同事的提交。如果要修改的不是最新一次而是更早的提交就需要git rebase -i配合reword了。这里最要强调的是修改已共享的历史前先和团队沟通否则会引发大量冲突。3.3 远程协作同步、推送、拉取题目七本地分支落后于远程且本地有未推送的提交如何安全整合推荐做法是分步执行git fetch origin git merge origin/main # 或者 git pull --rebase origin main直接git pull默认等于git fetch git merge如果本地有未推送的提交会生成一个合并提交。使用git pull --rebase则会把本地提交重放历史更线性但同样需要承担 rebase 的风险。如果本地提交已经推送到自己的远程分支且该分支只有你一个人用rebase 没问题。如果分支是共享的还是 merge 更稳。这题主要考查你是否理解 fetch 与 pull 的区别以及是否知道rebase会改写提交哈希。题目八如何丢弃本地所有未提交的修改且删除未被跟踪的文件git reset --hard HEAD git clean -fdgit reset --hard HEAD会把所有被跟踪文件的改动还原到 HEAD 状态git clean -fd会删除未被跟踪的文件和目录。这条命令非常危险执行后无法撤销除非文件之前被git stash或提交过。所以我通常建议先执行git stash --include-untracked把修改暂存起来确认不要了再清理而不是直接clean。这题如果上来就回答我会追问一句“确定不后悔吗”因为这是生产环境中破坏力最大的命令之一。3.4 撤销与恢复误操作急救题目九不小心执行了git reset --hard丢失了一次还未推送的提交如何找回答案是git reflog。reflog记录了 HEAD 的所有历史移动即使reset后原提交没有被任何分支引用只要还没有被垃圾回收就能通过哈希找回git reflog git reset --hard 丢失提交的哈希如果你不想移动当前分支也可以在新分支上git branch rescue 哈希。这是我最希望所有人都掌握的命令因为它相当于 Git 的后悔药。很多刚接触 Git 的人不知道 reflog 的存在一旦误操作就只能干着急其实只要 commit 过大部分情况都能捞回来。题目十误删了一个尚未合并的分支如何恢复思路和上一题一样先git reflog找到该分支最后一次指向的提交哈希然后git branch 分支名 哈希如果 reflog 中找不到还可以尝试git fsck --lost-found查找没有引用的悬空提交。恢复分支的操作不会影响当前工作区很安全。这个题是很好的加分题因为它考查的是“当工具没有直接提供按钮时如何用 Git 对象模型思考问题”。理解了 Git 的提交是不可变对象、分支只是指针这类恢复方案的思路自然就通了。题目十一只想把文件中的某几行改动暂存而不暂存其他改动怎么做git add -p filename执行后 Git 会按 hunk 分段询问是否暂存你可以输入y暂存当前段、n跳过、s拆分更小的段、e手动编辑。这是精细控制提交内容的重要技巧特别适合写代码时把无关调试代码和正经重构分开提交的场景。很多人习惯一次git add .结果提交里混入一堆print调试语句代码评审时很难看。注意git add -p只对已跟踪文件的修改有效对未跟踪的新文件要用git add -N先告诉 Git“我想跟踪它”。4. 实操过程把测验里的关键场景完整敲一遍4.1 搭建一个临时仓库来验证题目建议不要在自己的真实项目上试验危险命令单独开个目录来做mkdir git-quiz-lab cd git-quiz-lab git init echo version 1 app.txt git add app.txt git commit -m first commit这样一个干净的仓库就准备好了。接着模拟一个分支开发流程git checkout -b feature echo feature code app.txt git commit -am feature change git checkout main echo main code app.txt git commit -am main change git merge feature如果两个分支改了同一行就会产生冲突。你可以故意把两边都改成不同的内容再执行上面的 merge观察冲突标记长什么样。实际演练一遍比看十遍文档都有用。我在练习时还会顺手敲一下git status和git log --oneline --graph看看操作后提交图的变化这样能直观理解 merge 和 rebase 在历史结构上的区别。4.2 用一个分支合并冲突来演示完整流程假设app.txt两边都改了最后一行执行git merge feature时会报Auto-merging app.txt CONFLICT (content): Merge conflict in app.txt Automatic merge failed; fix conflicts and then commit the result.用cat app.txt查看内容你会看到带标记的文本。手动改成你想要的内容后git add app.txt git commit -m merge feature注意这里不需要-am因为合并提交需要明确的提交信息而且你已经手动 add 过了。如果在中途改了主意不想要这次合并可以执行git merge --abort回到合并前状态。这个命令也要记牢很多新手合并到一半发现冲突太多不知道怎么退出。如果换成 rebase 流程中止命令是git rebase --abort两者别记混。4.3 实战演示 reflog 找回被 reset 的提交继续在临时仓库里操作echo precious work app.txt git commit -am precious work git reset --hard HEAD~1此时git log中已经看不到precious work了。执行git reflog你会看到类似abc1234 HEAD{0}: reset: moving to HEAD~1 def5678 HEAD{1}: commit: precious work然后恢复git reset --hard def5678git log里那笔提交就回来了。整个过程不超过一分钟但这正是很多人不知道的救命操作。建议你自己动手敲一遍感受一下 reflog 的“时间机器”特性。我还喜欢给reflog加参数--dateiso能看到每次 HEAD 移动的具体时间排查“我到底什么时候搞坏的”这种问题时特别有用。5. 常见问题与避坑技巧实录5.1 最常见的错误操作和正确做法我在带新人时发现以下错误出现频率最高滥用git push --force这会直接覆盖远程历史如果同事基于旧提交开发会引发大量不必要的冲突。推荐用--force-with-lease。在错误分支上干活开发前忘记git checkout在一个已经过时的分支上改了代码。建议每次开始任务前git status确认当前分支。用git reset --hard丢弃改动如果没有先 commit 或 stash改动会永久丢失。想丢弃前先问自己一句能通过 reflog 找回来吗提交了不该提交的文件比如密钥、.env、依赖缓存。解决办法是提交前用git status和git diff --cached检查暂存内容并且养成写.gitignore的习惯。5.2 几个提升效率的小技巧第一配置简短的别名能让日常操作更快git config --global alias.co checkout git config --global alias.br branch git config --global alias.st status git config --global alias.last log -1 HEAD第二把git diff变成图形化对比减少大脑解析工作量。安装一个喜欢的 difftool 后git difftool就能调用它。第三使用git bisect定位引入 bug 的提交。步骤很简单选择一个坏提交和一个好提交然后反复回答“当前是否还出现 bug”大概七八次就能锁定问题提交。这几个技巧不属于考试范围但能实实在在改善日常体验。5.3 避坑自查清单操作意图安全命令危险命令原因放弃本地修改git stash或确认后git restore .git reset --hard后者无确认步骤容易误丢未提交内容推送修正后的提交git push --force-with-leasegit push --force后者不会检查远程是否变化取消合并git merge --abortgit rebase --abort混用不同流程对应不同中止命令找回误删分支git reflog后重建直接重新推一个相同名分支重建分支会覆盖原有引用且可能丢失提交查看暂存区差异git diff --cachedgit diff后者默认对比工作区与暂存区无法看到暂存内容6. 测验后续如何把 Git 真正学扎实6.1 从错题提炼复习重点做完这套测验如果发现自己有几道题答错了别急着焦虑。我个人的经验是把错题对应的命令在一个专用练习仓库里重复操作三遍第一遍看着笔记敲第二遍合上笔记盲敲第三遍换一个场景再敲一遍。三次之后基本能形成肌肉记忆。更重要的是把 Git 看成一套对象模型来学而不是死记参数。理解了提交是有向无环图、分支是指针、暂存区是中间层就会发现所有命令背后都是同一套逻辑。每次测验后我都会把错题记录成一个 Markdown 文件里面包含错误答案、正确答案和出错原因。一个月后再回来看看如果那类题已经能秒答说明进步明显如果还卡壳就该把相关概念的教程重新翻一遍。这种“错题本”方式看着朴素但比零散刷题有效得多因为它把每次踩坑都变成了长期记忆。6.2 建立自己的 Git 测验题库你可以把自己在工作中真实遇到过的 Git 问题收集起来按类别整理成自己的测验题。比如“同事的一个提交覆盖了我的提交怎么办”“分支名打错了如何重命名”“提交里误加了大文件怎么清理”。这些题目来自真实战场比网上现成的面试题更贴合你的业务场景。我自己的题库里大约有二十道题每隔一段时间就翻出来过一遍遇到新事故也会补进去。最后再分享一个小技巧可以给自己设置一个“每月一测”的提醒每次只需要二十分钟随机抽十道题快速回答。这个习惯我保持了很久收获是当线上出现分支事故时我能第一时间判断该怎么处理而不是打开浏览器临时搜命令。如果你也整理过自己的 Git 测验题目不妨也拉个清单用同样的方法测一遍自己练过的效果比单纯看别人的题目好得多。