Git核心技能实操：从安装配置到疑难杂症的全套考题与参考答案

很多刚接触 Git 的同学容易陷入一个误区：命令背了一堆，碰到真实项目还是一头雾水。最近我在团队内部做了一次 Git 核心技能摸底，把这几年踩过的坑、带新人时常遇到的问题、以及日常评审时发现的高频失误，全部揉成了一套实操考试题。考完之后我把这套题重新整理成了精编版，今天就把考卷和参考答案一起放出来。内容覆盖安装配置、本地提交、分支合并、远程协作、撤销回滚、过滤规则、疑难杂症七个层面，适合刚入职需要快速上手团队仓库的初级开发，也适合那些觉得自己“会用 Git”但遇到奇怪报错就慌的中级同学。

这套考题最大的特点是不考背诵，考操作。每一道题都对应一个真实工作场景，比如“SSH 认证失败”“commit 注释写错了”“大文件推不上远程”。你只需要把答案当作自己日常操作的记录，然后对照我给出的参考答案，看看哪里漏了、哪里走了弯路。

1. 这场“考试”的设计思路和考纲范围

1.1 为什么把 Git 当成一场实操考试来练

Git 这类版本控制工具，最大的学习障碍不是概念复杂，而是缺乏“不得不解决”的场景。很多人看完教程觉得懂了，一旦遇到真实报错就不知道从哪里排查。我在设计这套考题时，刻意把每个考点都放进一个模拟场景里，比如“你在 master 上写了三天的代码，现在要全部挪到 dev 分支去，怎么做”。这种题没有任何选项，也没有提示，能逼着你把命令敲出来，过程中你的操作习惯、对 Git 工作流的理解程度、遇到冲突时的判断力，全都会暴露出来。

考试的形式本身也是强化训练的一种手段。平时看教程是被动吸收，写着“git merge”的用法时你只是扫一眼；但当你必须在几分钟内合并两个分支并解决冲突时，大脑才会真正把命令和工作流绑定到一起。这也是为什么我一直建议团队新人不要只看文档，找一个临时仓库模拟推拉、合并、回滚，把每个命令敲到形成肌肉记忆。

1.2 考纲设计的四个层次：配置、提交、分支、远程协作

这套题的考纲不是随便列的，而是按照一个开发者的实际操作路径来分层。

第一层是环境，也就是安装和配置。过不了这一层，后面全是空谈。很多同学在 Windows 上装完 Git 就以为结束了，实际上还缺 Git Bash 的环境变量、换行符处理、SSH 密钥等一系列细节。

第二层是本地操作，核心是提交。add、commit、撤销、忽略规则这些都是一个人开发时最频繁用到的，也是最容易产生垃圾提交记录的元凶。

第三层是分支操作。包括 merge、rebase、cherry-pick 的选择，冲突解决，以及分支间代码转移这类实际工作中高频出现的问题。

第四层是远程协作。remote 管理、推送拉取、SSH 认证、Token 配置、IDE 集成，这些决定了你能否在团队里顺畅地把代码交付出去。

四个层次环环相扣，考试时我会刻意把远程和本地的问题交叉在一起，比如让你先修复本地的过滤规则，再推送大文件，考察你能不能分清问题发生的位置。

2. 必考基础：安装、配置和本地提交

2.1 不同系统的 Git 安装与验证

Windows 下最省心的方式是去 Git 官网下载 Windows 版本的安装包，安装过程中有几个选项值得注意。

第一个是“Select Components”，建议把“Git Bash Here”和“Git GUI Here”这两个右键菜单项勾上，后续在资源管理器里直接右键就能打开命令行，效率会高很多。第二个是“Default editor”，我一般会选择 VS Code，这样执行 git commit 进入编辑器时会自动拉起 VS Code，比默认的 Vim 对小菜鸟友好得多。第三个是“Adjusting your PATH environment”，一定要选“Git from the command line and also from 3rd-party software”，否则在 PowerShell 或 CMD 里敲 git 会提示找不到命令。第四个是“Line ending conversions”，通常选默认的 checkout as-is, commit as-is，或者选 Windows 风格转换，这两种各有适用范围，但如果团队里有不同系统的人，建议统一用默认。

macOS 其实系统自带的 Command Line Tools 里就包含 Git，在终端敲 git --version 如果提示找不到，执行 xcode-select --install 会自动安装。Linux 下走包管理器，Ubuntu 是 sudo apt install git，CentOS 是 sudo yum install git。

装完以后不要急着配置，先在终端跑一遍 git --version，再跑 git help，确认 Git 已经进入了你的命令行环境。这一步非常基础，但我见过很多人在 IDEA 里能提交代码，却在系统终端里敲不了 git，原因就是当时安装时选了不加入系统的 PATH 选项。

2.2 全局配置、SSH 密钥配置和“免密”到底怎么设

安装完成后的第一件事不是建仓库，而是给 Git 设置身份信息。

git config --global user.name "your-name" git config --global user.email "your-email"

这三条命令里的 --global 参数意味着这是当前用户范围内的全局配置，后续所有仓库默认继承。你需要确认邮箱和代码平台账号统一，很多人在 gitee 或 GitLab 上的头像不对，大概率就是 email 和平台账户不一致。

接下来是免密配置。我在这里特别强调一下，免密有两种完全不同的方案：

第一种是 HTTPS + 凭据管理器。Windows 上安装 Git 时默认会带上 Git Credential Manager，第一次推送时弹窗输入账号密码后，凭据会被缓存起来，后续不再要求输入。这种方式适合不熟悉 SSH 的用户，但在公司内网里如果凭证过期，会突然出现认证失败的报错。

第二种是 SSH 密钥方式。我个人的习惯是优先用 SSH，因为配置一次之后长期稳定，也不需要在每次 clone 时区分 https 地址前缀。生成密钥的命令：

ssh-keygen -t rsa -b 4096 -C "your-email"

一路回车可以在默认位置生成密钥。默认会在 ~/.ssh/ 下生成 id_rsa 和 id_rsa.pub 两个文件，私钥留在本地，公钥内容填到代码平台的 SSH keys 管理页面。验证是否配置成功：

ssh -T git@github.com

如果提示成功认证，那就彻底进入免密状态。很多人卡在这一步是因为多把密钥导致 agent 识别错，这时候可以新建配置文件 ~/.ssh/config，给不同平台指定 IdentityFile，实测下来非常管用。

2.3 第一次提交代码：add、commit 的正确姿势与提交信息规范

提交是日常最高频的操作，但大部分人的姿势并不正确。最常见的流水账式提交是一口气把十几个文件的改动全部 add 进去，然后写一条“更新代码”的注释糊弄过去。这种方式在个人项目里暂且能忍，放在团队代码评审里就是灾难。

推荐的做法是提交前先看状态和差异：

git status git diff

git status 能告诉你哪些文件被修改、哪些是新增、哪些被删除，git diff 能逐行查看未暂存的改动内容。确认改动符合预期后，再把相关文件加入暂存区：

git add src/controller/UserController.java git add src/service/UserService.java

这次只提交和登录逻辑相关的改动，注释写成“修复用户登录时密码加密的失效问题”，下次别人翻历史时能一眼明白这次提交做了什么。这个习惯叫原子提交，意思是每次提交只做一件事，回滚起来也精确。

提交注释的规范也是很多团队在评审时的硬指标。可以用一句话概括核心，也可以配合正文说明背景，比如：

git commit -m "修复登录接口密码校验失败的问题" -m "原因是前端传入了未编码的明文，后端在比较前需要先做一次 SHA-256 处理"

首次提交时如果提示 global user.email 没设置，说明刚才的全局配置没有被当前仓库读到，这时候除了重新执行 git config --global 外，也可以通过 git config user.email 来设置仅在当前仓库生效的本地配置。

3. 高频实操沙坑：撤销、拣选和合并

3.1 git commit --amend 和 git revert：两种后悔药的适用边界

实操中最常被问到的就是“注释写错了怎么办”和“提交了错误代码怎么回退”。这两件事的处理方式完全不同。

如果你刚 commit 完，发现注释有拼写错误，或者漏掉了一个小文件，可以用：

git commit --amend

这个命令会把当前的暂存区内容追加到上一次提交中，同时允许你修改注释。说白了就是把两次提交合并成一次。打开编辑器修改注释后保存退出，上一次提交的 hash 会变化，所以这条命令只适用于还没推送到远程的提交。一旦推送到了公共远程分支，amend 会在一瞬间重写历史，team里其他人原本基于旧提交的工作就全乱套了。

如果你想撤销一个已经推送到远程的提交，或者撤销一个几小时前完成的提交，正确选择是 git revert。我经常跟团队同学讲一句话：commit --amend 是改昨天打翻的汤，revert 是给今天上错的菜再加一道新菜。revert 不会删除历史，而是生成一个反向的新提交，把之前的改动撤销回来。

git revert <commit_id>

执行后 Git 会帮我们创建一个新的提交，这个提交的内容正好是旧提交的逆操作。它的优势是历史记录完整，代码评审时能明白“谁在什么时候用什么操作干掉了哪次改动”，这也是 revert 在多人协作中比 reset 安全得多的原因。

如果非要彻底抹除一段历史，那才考虑 git reset，通过 --hard 参数回到某个提交点。这种操作会丢掉之后的所有改动，而且会影响所有已经拉取过这段历史的协作者。我的建议是：个人分支随便折腾，公共分支一律 revert，不要 reset。

3.2 merge、pick、fetch、pull 之间的关系与正确选择

很多同学把 fetch 和 pull 混为一谈，把 cherry-pick 和 merge 的关系也理不清，我用一个生活化的类比来解释。

fetch 只是把你的远程更新记录下载到本地，它不会改动你当前的工作目录和本地分支。也就是说执行完 git fetch 后，你可以先看看 origin/main 到底多了哪些新提交，再决定怎么处理。而 pull 是 fetch 加 merge 的组合，它会直接把远程分支的最新状态拉下来并尝试合并到当前分支。如果你当前有未提交的改动，pull 大概率会报错或产生冲突。

在团队协作中，我建议每次正式合并前都手动 fetch 一下，然后查看差异再合并，避免手一抖就引入大范围冲突。频繁 pull 是不少“代码突然没了”事故的元凶，因为 pull 在一定场景下会把本地还未提交的改动覆盖掉。

cherry-pick 则是摘樱桃式操作，它的作用是挑一个别的分支上的提交，落到当前分支上来。这个命令在跨分支修复 Bug 时非常好用。比如你在 main 分支修复了一个线上 Bug，提交编号是 abc1234，现在需要让 release 分支也带上这个修复，又不想把 main 分支整个合并过来，就可以切到 release 分支后执行：

git cherry-pick abc1234

这个功能解决了开发流程中的分支隔离问题。如果需要在多个分支应用同一个修复点，cherry-pick 几乎是最干净的方案。但要注意，cherry-pick 会生成一个新的提交 ID，如果后续源分支又改动了这个提交，不会自动同步到目标分支。

3.3 分支合并的冲突处理，和“把 master 上的代码挪到 dev”的操作

分支合并是多人协作里绕不开的关卡。我整理了一道高频题：有同事问“我在 master 上写了两天代码，现在发现应该写到 dev 上，怎么把代码挪过去”。这道题的完整流程是：

git stash git checkout dev git stash pop

先用 stash 把当前未提交的改动暂存起来，再切换分支到 dev，最后把暂存的改动弹出来。但如果改动已经提交到了 master，流程变成：

git checkout dev git merge master

如果想要的是把 master 上全都搬到 dev，这种方式最简单。如果只想搬某几个提交，那就要前面的 cherry-pick。

合并时的冲突是最让人头疼的。出现冲突后 Git 会在文件里标记 <<<<<<< HEAD 和 >>>>>>> [分支名]，你需要手动打开文件逐段选择保留。解决后不要直接提交，而是把冲突文件重新 add，再执行：

git add . git commit

这里要格外注意：如果有多个文件冲突，千万别用 reset 回退，否则会丢掉已经解决好的部分。我先手动解决 A 文件的冲突，再把 B 文件里某一个版本丢弃，也请在编辑器里仔细确认每个冲突标记被清理干净了再把文件加入暂存区。

IDEA 这类 IDE 提供了图形化的冲突解决工具，左右分栏展示两个版本的内容，还能选择“合并后的中间版”。但图形化工具并不能取代命令行理解，如果不懂底层的 merge 机制，图形界面上点错了反而更麻烦。

4. 远程仓库协作：remote、推送失败与认证问题

4.1 git remote 管理与多远端切换

远程仓库协作的第一步就是管理 remote 地址。clone 后默认会有一个名为 origin 的远程仓库，但实际工作中经常需要同时对接多个远端，比如开源项目需要往上游提交、公司内部又要推到自己的镜像仓库。

查看当前所有远端：

git remote -v

添加一个新远端，比如添加一个 gitee 仓库：

git remote add gitee https://gitee.com/xxx/project.git

推送时不推给 origin，而是推给 gitee 对应的分支：

git push gitee main

修改已有远端地址：

git remote set-url origin <new-url>

远端管理属于基础但很少训练的操作，很多同学在离职交接或者更换 GitLab 地址后，连 git remote set-url 都不知道，只能删掉整个仓库重新 clone，效率极低。

注意检查远程地址用的是 SSH 协议还是 HTTPS 协议。如果地址是 git@github.com 开头，那是 SSH；是 https:// 开头那就是 HTTPS。两种协议的认证方式和报错信息完全不同，后面排查认证问题时要先分清协议类型。

4.2 SSH 认证失败、GitHub token 配置、Gitee 密钥配置的排查思路

SSH 认证失败是高频疑难杂症，它的典型报错是 Permission denied (publickey)。这类问题我总结了一个排查顺序。

第一步检查密钥是否存在：

ls -l ~/.ssh/

如果发现没有 id_rsa 和 id_rsa.pub，那就先重新生成密钥。

第二步确认公钥已经添加到平台。GitHub 上在 Settings -> SSH and GPG keys 里添加，Gitee 在安全设置里的 SSH 公钥页面添加。公钥内容用：

cat ~/.ssh/id_rsa.pub

复制输出内容时小心别漏掉末尾的邮箱注释。

第三步测试连接情况：

ssh -T git@github.com ssh -T git@gitee.com

如果 GitHub 上能通，Gitee 上不通，说明是这个平台上的公钥没有上传或上传内容有误。

第四步检查权限是否正确，这也是新手容易忽略的。~/.ssh 目录权限必须是 700，id_rsa 私钥文件权限必须是 600。某些 Windows 环境下的用户目录权限乱了，会直接导致 SSH 客户端拒读私钥，报错同样会伪装成 publickey 拒绝。

公司 GitLab 这类场景还可能涉及 HTTPS 的 token 认证。GitHub 很早之前就取消了密码推送，现在必须用个人访问令牌，也就是 Personal Access Token。在 GitHub 的 Settings -> Developer settings -> Personal access tokens 里生成一个具有 repo 权限的 Token，推送时的用户名填写你的 GitHub 用户名，密码框填写 Token 字符串。很多同学在命令行或者 IDEA 里反复提示登录失败，就是这个原因。

4.3 IDE 场景：IDEA 中拉取项目、合并分支的常见操作

IDE 集成 Git 确实降低了上手门槛，但操作姿势不对仍然会埋雷。拿 IDEA 来说，新建项目后拉取 Git 仓库，正确的入口是 File -> New -> Project from Version Control，然后在 URL 里粘贴仓库地址。有些同学会先建一个空项目再配置 remote，这样容易导致本地项目结构和远程仓库完全错位。

IDEA 里合并分支通常在右下角的 Git 分支状态区域选中目标分支，点击某个分支再选择 Merge into Current。合并前一定要先看当前的分支名，很多事故都是在 release 分支上不小心合了 develop，或者反过来了。

还有一个细节，执行 Pull 时 IDEA 默认会打开一个 Rebase 选项，不少同学不理解就乱勾。如果团队没有明确要求 rebase 模式，建议保持 Merge。反复切换 Rebase 和 Merge 会导致提交历史乱成一团，尤其是同一个作者的名字在 graph 上会反复出现多条线。

IDEA 里还经常遇到 open /dev/null or dup failed: no such file or directory 这类报错，实际上这是文件句柄达到上限或路径太长的问题，跟 Git 关系不大，但还是有人在网上搜半天找不到答案。解决办法通常是关闭多余文件、清理缓存，或者重启 IDEA 清理文件端口占用。

5. 过滤规则与疑难杂症：大文件、忽略规则、目录泄露

5.1 .gitignore 不生效的真正原因与排查方法

这是一个极其高频的“疑难杂症”：我在 .gitignore 里写了 target/，但 git status 还是能看到 target 目录下的文件。原因不是规则写错，而是这些文件已经被 Git 跟踪了。gitignore 只对尚未被跟踪的文件生效。对于已经被纳入版本控制的文件，修改忽略规则并不能让它自动停止跟踪。

解决办法是先解除跟踪，再把文件加入忽略规则：

git rm -r --cached target/

这一步的 --cached 参数很关键，它表示只从索引里移除文件，不影响你本地磁盘上的源文件。执行完后再看一下 git status，target 下的文件就不再出现了。最后提交一次，提交的内容就是“移除 target 目录的版本控制，并更新忽略规则”。

我见过很多人在这时候用了 git rm -r target 而不是带 --cached 的版本，结果本地源文件被删了，还要靠远程仓库重新拉取，白白浪费半天时间。另外写忽略规则时注意不要犯模式错误，比如 /build/ 和 build/ 的含义不同，前者只能匹配根目录下的 build，后者匹配任意层级的 build。不想让某个目录被跟踪就把规则写得绝对一点，避免误伤。

5.2 Git 无法提交大文件的处理：仓库瘦身和替代方案

很多团队在项目发展到一定阶段会遇到一个坑：某次推送发现 Git 直接拒绝了，提示文件太大超过几百万字节。很多代码平台都有单文件大小限制，比如 GitHub 的标准上限是 100 MB。遇到这种问题第一反应不是提交到普通仓库，而是判断这个文件到底该不该进仓库。

如果是项目运行必不可少的资源文件，比如设计稿素材包、视频演示、数据库快照，传统 Git 其实并不适合存这些大文件。Git 是为源代码设计的，每一次提交都会在 .git 目录里完整保留文件快照，大文件一旦进入仓库再删掉，历史里的宝箱还是会被所有 clone 的人下载一遍。

正确处理是用 Git LFS 解决方案。项目里安装 Git LFS 插件，声明哪类文件走 LFS 存储：

git lfs install git lfs track "*.psd" git add .gitattributes git add your-file.psd git commit -m "add psd via lfs"

如果已经把一个 1 GB 的文件提交进仓库导致远程被拒，才算真正进入疑难杂症。首先要从暂存区移除这个文件，再考虑重写历史。重写历史的过程比较危险，建议在不影响团队其他人的前提下，用 git filter-branch 或者 git filter-repo 工具操作。我个人的建议是大部分中小团队直接“断舍离”，把含大文件的分支历史用 reset 清理到干净状态，再重新推送。

除了技术方案，还要在团队层面立规矩：大文件统一放到文件共享服务，仓库里只放文本清单或部署脚本的引用。能从根本上杜绝这类问题。

5.3 目录泄露、资源站托管的一类非典型场景

热词里提到的“git 目录泄露如何下载”，是指某些线上站点把 .git 目录错误地部署到了公开访问的服务器上，访问者可以直接通过 .git 目录里的对象信息还原出源仓库代码。这类安全问题风险极高，相当于把源代码零成本地暴露了出去。

从防御角度看，部署 Web 应用时，一定要把 .git 目录排除出静态目录列表，或者直接不把仓库文件拷贝到服务器发布目录。Nginx 下可以通过配置 deny 来禁止外部访问：

location ~ /\.git { deny all; }

从攻防演练或者安全测试队伍的角度看，检测 .git 目录泄露的常规操作是先访问域名下的 /.git/HEAD 看是否存在，如果存在就需要评估泄露范围并通知对应负责人。这个知识点的核心是安全意识，源码泄露的危害远大于配置错误本身。

关于“博主「谁悲失路之人」分享的高性价比人生指南开源资源站，托管在 git”这类非典型场景，我想说的是，Git 托管平台完全可以用来托管文档、配置模板、资源清单这类非代码内容。只要保持内容合规、仓库公开策略正确，Git 仓库本身就是一个轻量级的内容协作工具。把资源站仓库规模控制好，使用方便的 Git 命令来维护更新，也能成为一个可持续的数据库。

6. 常见问题速查与避坑清单

6.1 一批真实场景的错误信息对照表

这张速查表是我把团队日常答疑里高频问题抽出来整理的。可以看到大部分疑难杂症都不是 Git 本身复杂，而是环境串味了：认证问题、权限问题、代理问题、文件系统问题，全被包装成 Git 的报错。遇到报错时先别急着复制到搜索引擎，看清报错里的关键词是在哪个环节，比瞎搜强一百倍。

6.2 我个人的实操习惯和最后几点建议

这套“Git 核心技能实操强化考试（精编版）”考完之后，团队里明显减少了一种现象：几个人围在一起对着一个分支合并的问题开会讨论。我自己的实操习惯也在这个过程中被固化下来。

第一，每次提交前先跑 git status 和 git diff。哪怕改动只有一行，也值得看一眼。很多不小心把密钥文件、日志文件带上来的事故，都是因为不看状态直接 add 全部。

第二，公共分支上一定用 revert 而不用 reset。我不止一次见过有人为了“消除某次错误提交”把共享分支直接 reset，导致其他人 pull 时一屏幕的冲突，最终只能全体重新 clone。

第三，遇到卡住的问题先看协议和远端地址。SSH 认证失败，先看密钥权限和公钥有没有上传；HTTPS 失败，先看 token 是否过期。这样排查速度最快。

第四，IDE 里的分支操作要时刻留意当前分支名。合并之前先看右下角，Push 之前先看 Pull 是从哪个远端拉的，很多事故都是“切错分支后盲目操作”引起的。

第五，不要把秘密文件推到哪怕私有仓库。代码平台的内存和权限再严格，也扛不住密钥文件被下载散播。规则写在 .gitignore 里永远不如密钥压根不进仓库来得安全。

这套考卷的价值不在于让你背命令，而是帮你建立一套条件反射：遇到“代码没了”“提交错了”“推到一半失败”的时候，第一反应应该是去检查哪一层状态，而不是复制报错到处找人问。我把题目和答案都摆在这了，也建议你拿一个临时仓库从头到尾敲一遍，把每个步骤变成自己的本能操作。代码管理这件事，越早建立体系化习惯，后面省下来的时间就越多。