准备Git面试题最怕什么？怕背了一堆命令参数，结果面试官换个角度问就懵了。这几年我面过不少候选人，也帮团队做过技术招聘，发现Git相关的考察真不是让你背命令，而是看你有没有真正理解这个工具背后的设计逻辑。我梳理了一份按面试维度组织的Git核心题目清单，从基础概念到分支管理，再到撤销回滚和日常疑难杂症，每道题都附带我实际用下来的思考和踩坑经验。
不管你是准备跳槽的开发者，还是刚接触Git不久想系统补课的新人，这篇文章都能帮你把Git的知识体系补完整，而不是零散地记一堆命令。
1. 基础概念高频题：先搞清楚Git到底是什么
1.1 面试必问：Git和SVN的本质区别在哪里
这个题目基本属于一面必问，但很多人答不好。常见的回答是“Git是分布式的，SVN是集中式的”，然后就没了。这样答太单薄，面试官其实想听的是你对这两种架构差别的真实理解。
我在实际使用中的体会是，分布式和集中式的根本差异体现在三个层面。首先是本地仓库的存在。Git每个开发者本地都有一个完整的仓库，包含全部历史记录，这意味着断网也能提交代码、查看历史、创建分支。SVN不行，SVN的每次提交、每条日志都需要连接中央服务器。其次是分支的代价。Git的分支本质上是指向提交的可移动指针，创建和切换都极快，所以能支撑高频分支操作。SVN的分支是在服务器上拷贝目录，操作笨重。最后是数据安全模型。Git的每次提交都会计算内容的SHA-1哈希，历史记录从设计上就很难被篡改，而SVN的元数据集中在服务器，一旦服务器故障风险就很大。
我建议你这样回答：先点明分布式和集中式的架构差异，再用两个实际场景佐证——比如多人同时在多个分支上开发时Git的灵活性，以及本地提交对开发效率的提升。
1.2 三个工作区域和文件状态流转，一张图记牢
Git里的文件会经历四种状态：未跟踪、已修改、已暂存、已提交。对应的是三个区域：工作区、暂存区、本地仓库。
我在给团队做培训时常说，你先记住一条主线：修改文件是在工作区操作，add之后进入暂存区，commit之后进入本地仓库。理解了这个流转，绝大多数命令就能自己推出来。比如git diff看的是工作区改动，git diff --cached看的是暂存区改动，git diff HEAD看的是已提交和暂存加起来的总改动。
容易被忽视的一点是已跟踪文件的修改状态。工作区里一个已跟踪文件被你改过之后，如果还没add，git status会显示“Changes not staged for commit”，这时候commit并不会包含这个改动。很多刚用Git的人在这个地方翻车，以为改了文件直接commit就行，结果发现提交里没有自己的修改。
我建议面试时主动提一个细节：新建文件必须add之后才会被跟踪，否则git commit .不会把它带上。这个细节能体现你真的用过Git，而不是只背了概念。
1.3 .git目录里到底藏了什么
这个问题面试官很少直接问，但理解它有很多好处。执行git init之后，项目根目录会出现一个.git文件夹，里面是这个仓库的全部元数据和对象数据库。
我拆开看过，核心内容有这几类。HEAD文件记录当前检出的分支或提交；config文件存放仓库级别的配置；objects目录存放所有的数据对象，包括提交对象、树对象和内容对象；refs目录存放分支指针和标签指针；index文件就是暂存区的事实存储。
我踩过的一个坑是：不小心把.git目录删了，然后发现整个历史记录全没了，只剩下工作区文件。重新git init的话，所有提交历史都归零。后来我养成一个习惯，重要项目一定会做裸仓库备份，也就是用git clone --bare把仓库完整复制一份到服务器上。这个小技巧能有效避免仓库意外损坏导致的历史丢失。
2. 分支与合并核心题：面试官真正想考察的点
2.1 Merge和Rebase到底怎么选，不要再说“差不多”
Merge和Rebase是Git面试里最容易暴露水平的一道题。很多候选人能说出“merge会生成合并节点，rebase会变基”，但问到什么时候用哪个就含糊了。
我个人的理解是：merge保留了真实的开发历史，rebase让历史变成一条直线，两者本质区别体现在提交历史上。Merge执行后会产生一个新的合并提交，它的父节点有两个，能清晰看到哪些分支参与了合并。Rebase则是把你当前分支的提交一个个摘下来，嫁接到目标分支的最新提交之后，最后得到一条线性历史。
举个例子。你在feature分支上做了3次提交，master分支上有别人新推了2次提交。如果执行git merge master，Git会生成一个合并节点，历史呈分叉状。如果执行git rebase master，Git会先把你的3次提交的补丁保存下来，然后以master的最新提交为基底，重新生成3个新提交，它们的父节点是master最新的那个提交。
我在公司里遵循的原则是：提交到共享分支之前先rebase保证历史整洁，但绝不对公共分支上的提交做rebase。原因很简单，rebase会改变提交的哈希值，如果别人已经基于你原来的提交做了开发，你rebase之后再推上去，对方的本地历史就和远端对不上了，就会遇到一堆合并冲突。这也是面试官最想听到的点：rebase适合个人开发分支整理，merge适合公共分支合并。
2.2 冲突是怎么产生的，解决思路比命令更重要
只要多人协作，冲突就是躲不开的话题。面试官问冲突，重点往往不是命令，而是你是否清楚冲突的本质。
冲突的产生是因为两个分支修改了同一位置的内容，Git无法自动判断哪个版本是正确的。比如你和同事同时改了同一个文件里的同一行代码，你们各自提交之后，无论是merge还是rebase，Git都会在合并时停下来，提示你手动解决。
我在实际协作中总结了一套冲突处理流程。先用git status找到冲突文件，冲突文件中会标注<<<<<<<、=======、>>>>>>>这三种标记，分别对应当前分支、公共基础、合并进来的分支的版本。然后手动编辑文件，把冲突标记删掉，保留正确的代码。解决后执行git add标记为已解决，最后用git commit结束合并。如果是rebase过程中冲突，解决完add之后直接用git rebase --continue继续。
说一个容易忽略的点：冲突文件不一定是双方改了同一行，也可能是某人改了文件内容，另一个人删除了这个文件，Git同样无法自动合并且会提示冲突。这类冲突解决时要先和对方确认意图，到底该保留还是删除。
2.3 Git Flow和主干开发，团队分支策略怎么答
面试问到分支策略，通常是想了解你有没有参与过规范的团队协作。我工作中用过多种策略，最经典的Git Flow和现在流行的主干开发各有适用场景。
Git Flow划分了五类分支：master存放可发布的正式版本，develop作为集成分支，feature用于功能开发，release用于发布准备工作，hotfix用于紧急修复线上问题。这种策略流程严谨，适合发版节奏固定、需要同时维护多个版本的团队。缺点也很明显：分支太多，操作繁琐，持续集成的响应速度会受影响。
主干开发则是所有开发者在主干分支上频繁提交小步改动，配合功能开关控制发布内容。这种策略简单直接，配合CI/CD能实现快速交付，适合以持续发布为目标的互联网团队。
回答这类问题时，我建议不要只罗列概念，而是从团队规模和交付节奏出发，说说哪种策略适合什么场景，以及如果策略不适合会带来什么麻烦。面试官更想看到你有真实的决策判断力。
2.4 分支相关的几个高频命令：worktree、cherry-pick、stash
除了merge和rebase，还有几个分支操作命令同样值得掌握，因为它们在实际开发中非常实用。
git worktree是我近两年用得越来越多的命令。它允许你在同一仓库上同时检出多个工作目录。比如你正在feature-A分支上开发，突然要紧急修复线上bug，不需要stash当前工作再切换分支，直接git worktree add ../hotfix-fix -b hotfix/fix-bug，就可以在另一个目录里基于当前代码创建并检出新分支。这个命令在需要并行处理多个任务场景时效率提升非常明显。
git cherry-pick用来把某个提交的改动应用到当前分支。举个例子，线上有个紧急bug，在开发分支上已经修复并提交了，这时候只需要git cherry-pick那个修复提交的哈希值，就能把这个修复带过来，不用整个分支合并过去。但要注意，cherry-pick生成的提交是全新的提交，和原来的提交哈希不同，所以如果两个分支将来还会合并，可能会遇到重复修改的冲突。
git stash的作用是临时保存未提交的改动。遇到需要切换分支但工作区有改动的情况，git stash将改动保存起来，工作区恢复干净。git stash pop可以把改动恢复。我带新人时常说，stash是“临时放一下”的操作，但别依赖它保存重要代码，因为stash栈容易被遗忘，时间久了谁都不记得里面存了什么。
3. 撤销与回滚场景题：这些场景几乎每天都会遇到
3.1 工作区、暂存区、本地仓库分别怎么撤销
撤销是Git面试的必考题，也是日常使用频率最高的操作之一。不同区域的撤销方式不同，我按区域给你拆开讲。
工作区改乱了，想还原到最近一次git add或git commit时的状态，用git checkout -- 或新版Git推荐的git restore 。这个操作会把工作区文件覆盖，未提交的修改会丢失，执行前想清楚。
暂存区里已经有了改动，但你想取消暂存，用git reset HEAD 或git restore --staged 。注意，这个操作只是把文件从暂存区移回工作区，文件内容本身不会被修改。
已经commit了，但发现提交有问题，想撤销这次提交，那就要用git reset或git revert，后面展开讲。
我建议面试时主动补充一个细节：git restore --staged之后，文件处于已修改未暂存状态，内容还在工作区，所以不会丢失。很多候选人分不清“取消暂存”和“撤销修改”，这两个概念在面试里很容易被追问。
3.2 reset的三种模式，软、混合、硬到底影响什么
git reset命令有三种模式，这也是Git面试中比较难讲清楚的一个知识点。简单说，三种模式的区别在于重置后哪些区域会被恢复。
git reset --soft HEAD~1意思是将HEAD指针回退一个提交，但暂存区和工作区保持不变。换句话说是撤销commit这一动作，但是add过的内容还在暂存区。如果提交后发现漏了几个文件，但又想保留暂存状态修改后再提交，用这是一次比较合适的场景。比如你用git commit提交后发现忘了add一个文件，执行git reset --soft HEAD~1之后重新add再commit，就能得到一个新的提交。
git reset --mixed是默认模式，执行git reset HEAD~1等同于git reset --mixed HEAD~1。它会回退HEAD指针，同时将暂存区重置为回退后的提交状态，但工作区的文件内容不会变。效果就是撤销commit且撤销暂存，但你的修改还在工作区，只是变成了已修改未暂存状态。
git reset --hard HEAD~1会回退HEAD指针，同时重置暂存区和工作区，让它们都回到回退后的提交状态。这个操作会丢弃当前未提交的全部改动，执行后不可恢复（除非用了reflog），使用时要格外谨慎。
我在团队里给新人的建议是：个人开发分支可以大胆用reset；公共分支严禁用reset，因为会重写历史，影响所有基于这个分支开发的同事。
3.3 revert和reset，什么时候用哪个
Revert和reset都用于撤销，但使用场景完全不同。这是面试官喜欢拿来考察深度的一个点。
Reset是移动分支指针，直接丢弃历史。比如git reset --hard HEAD~1会删除最新提交，分支指向上一个提交，历史被改写。如果用reset撤销了已推送到远端的提交，再push时必须加--force，而且会影响其他人。
Revert则是生成一个反向提交。git revert HEAD会创建一个新的提交，内容刚好抵消掉HEAD那个提交的改动，历史始终向前推进，不会改写已有提交。
我的原则很简单：只要提交已经推送到远端或可能被其他人使用，就必须用revert。如果只是本地还没推送的提交，用reset更干净。这个规则在团队协作中非常重要，因为rebase、reset这类改写历史的操作一旦发生在公共分支上，就会让所有人的同步变得混乱。
3.4 amend怎么用，如何修改最近一次提交
热词里专门有git commit --amend，说明这个命令确实高频。它的作用是修改最近一次提交，可以把漏掉的文件加进去、修改提交信息、甚至把多次提交合并成一次。
最常见的场景是提交之后发现漏了一个文件。你刚执行git commit，突然想起来还有一处改动需要提交，这时候直接git add漏掉的文件，然后git commit --amend，Git会用新的提交替换原来的提交，不会生成额外的提交记录。
另一个场景是提交信息写错了或不规范。执行git commit --amend，会进入交互界面让你修改提交信息。如果想直接用命令行修改，可以用git commit --amend -m "新的提交信息"。
要注意的是，amend本质上是创建一个新的提交替换旧的提交，所以提交哈希会变。如果这个提交已经推送到远端，同样不要直接amend，否则就会导致远端历史和本地不一致。我在实际工作中遇到的典型翻车现场是：某同事把commit推到了共享分支，然后又amend，下次pull就报了“远端和本地分叉”的提示，处理起来很麻烦。
3.5 reflog，Git的后悔药
git reflog是Git里相当有用的“后悔药”机制，但很多开发者不了解它。它记录的是HEAD指针的每一次移动，包括reset、rebase、commit、checkout等操作。
为什么reflog能救命？因为Git不会立刻删除未被引用的提交对象。假设你执行了git reset --hard HEAD~3，把最新3次提交都丢掉了，这时候只要还在reflog记录里，就能找到原来的提交哈希值，然后git cherry-pick或git reset --hard 把提交找回来。
reflog记录默认会保留90天，这个时间窗口足够你发现自己操作失误并找回数据。我使用Git这些年，reflog真正帮我找回了不少以为已经丢失的提交。面试时讲到reflog，如果还能顺带说清楚它的机制和保留周期，会显得确实有实战积累。
4. 日常使用与疑难杂症：真刀真枪踩过的坑才有价值
4.1 SSH密钥配置和连接Gitee这类平台的流程
配置SSH密钥是Git使用的基础操作，也是面试中容易被当作小问题考察的环节。整体流程其实不复杂，但不少人卡在概念上。
首先在本地生成密钥对，执行ssh-keygen -t ed25519 -C "你的邮箱"。ed25519是比rsa更轻量、更安全的算法，现在的新项目我都推荐用它。生成的公钥默认存放在~/.ssh/id_ed25519.pub，私钥在~/.ssh/id_ed25519。
然后把公钥添加到代码托管平台。以Gitee为例，在设置里的“SSH公钥”页面粘贴公钥内容，保存即可。配置完成后可以执行ssh -T git@gitee.com测试连通性。首次连接会提示确认指纹信息，输入yes即可。
这里有一个容易踩坑的地方：如果之前已经生成过rd或ed25519密钥，新密钥可能不会被默认加载。如果连接失败，先检查~/.ssh/config文件是否配置了正确的密钥路径，也可以用ssh-add -l查看当前加载的密钥列表。还有一个细节，执行ssh -T时提示的远程用户是git，不是你的用户名，这是Git over SSH的统一约定，别弄混了。
4.2 Git小乌龟这类GUI工具，值不值得用
热词里出现了“git小乌龟”，这是TortoiseGit的中文昵称。很多刚从SVN迁移到Git的团队会用它，因为它和TortoiseSVN的交互方式很像，在Windows资源管理器里右键就能操作。
我的态度是：GUI工具可以做入门辅助，但不建议完全依赖。原因在于Git的很多高效操作，比如交互式rebase、cherry-pick多个提交、查看reflog，在GUI里反而不如命令行直观。而且面试时考察的是你对Git本身的理解，不是在某个工具上的熟练程度。
如果你正在熟悉Git，我建议这样组合：日常提交、拉取、推送可以用GUI辅助，但涉及分支合并、历史改写、冲突处理时切到命令行，这样更能理解Git每一步在做什么。另外JetBrains系列IDE内置的Git集成做得也不错，尤其要说的就是看代码每一行的提交归属，这类操作比命令行高效很多。
4.3 常见报错的排查思路：fatal、登录失败这类问题怎么破
Git使用中报错是常态，排查思路比记住每个报错更重要。我把实际工作中遇到的高频报错整理成一个速查表，方便你遇到问题时对照。
fatal: not a git repository (or any of the parent directories): .git，这个报错出现的原因是你当前不处于Git仓库内。解决方案是切换到仓库根目录或子目录，或者重新执行git init。我遇到过不少同事在某些系统目录下执行git命令，自然就报这个错。判断当前目录是否在仓库内，可以用git rev-parse --show-toplevel查看。
fatal: refusing to merge unrelated histories，这个在合并两个没有共同祖先的分支时会出现，比如把两个独立的仓库合并在一起。如果确认两个仓库确实属于同一个项目，可以用git merge --allow-unrelated-histories强制合并。但要注意，这种方式合并后往往冲突很多，需要逐一处理。
login failed. check api token or gitlab version. log in via git if the versi开头这个这个报错一般出现在IDE访问GitLab时，排查思路通常是token过期、API版本不匹配或账户权限变动。解决方法是先在IDE的账户设置里重新登录，更新访问令牌。
The requested URL returned error: 403，通常表示没有权限推送。检查一下是对代码仓库的权限配置有问题。还有一种情况是已经用其他账号登录过Git，credentials缓存里存了旧账号的信息，导致新身份无法推送。
我给你的建议是：报错信息里的关键词比报错本身重要。不要只看最后一行，要从头阅读完整日志，很多时候真正的问题藏在更前面的输出里。能完整贴出报错，也是团队协作中比较基本的沟通素养。
4.4 目录泄露的风险意识与安全提醒
热词里的“git目录泄露如何下载”涉及的是安全话题。当一个网站的源码目录下存在可访问的.git目录，攻击者就可以利用git工具把整个源代码下载下来，从而获取未加密的敏感信息，比如数据库连接配置、密钥等。
从开发者的角度，我认为需要建立这样的安全意识：仓库上线前应确认.git目录不会被部署到公网环境。常见的做法是配置Web服务器规则，禁止访问.git目录。比如在Nginx里加一条location规则，或者在项目发布流程中过滤掉.git目录。
这类问题背后反映的是工程化流程的疏漏。我在做代码审查时会关注构建产物是否包含版本控制元数据，部署脚本是否做了排除处理。安全问题的本质往往不是单个文件泄露，而是整个发布流程缺少标准化检查。
4.5 面试回答Git问题的三个小原则
最后分享三个我在面试候选人时比较看重的原则，也是我自己回答Git问题的经验总结。
原理优先于命令。一道题目如果能先讲清楚底层原理再推导出命令，比生硬背出一串参数好得多。面试官问merge和rebase的区别，最好先从提交对象的结构说起，然后自然引出两种操作的不同。
场景优先于记忆。准备Git面试题时，不要按命令去记，而是按场景去思考：提交消息写错了怎么办、想丢弃某个分支的改动怎么办、历史已经推送到远端还能改吗。把场景想透了，命令自然就记住了。
协作优先于技巧。Git本身是协作工具，任何操作都要想到是否会影响队友。我在团队里定的规矩是：push之前先思考这个操作是否改写了公共历史，如果改写了就要慎重考虑是否真的需要。理解这一点，就已经超过不少面试候选人了。
Git的知识体系看着分散，但核心逻辑其实是清楚的：理解对象模型和引用机制，然后围绕工作区、暂存区、仓库这三个区域去推导具体操作。准备面试的时候不要死记命令，把每个操作背后的原因和场景想明白，面试官问再深也不怕。
