Git 回退版本三兄弟：reset、revert、checkout/restore 深度解析

1. 先说清楚“三兄弟”到底是谁

写代码这几年，几乎没人能躲过“改错了想回去”的瞬间。代码跑得好好的被你一顿重构改崩了，提交记录推到远端发现同事拉下来跑不起来，或者刚写完功能发现方向完全理解错了——这些场景都需要把代码回退到之前的某个状态。在 Git 里，能完成“回退”这个动作的命令不少，但真正高频、好用、能覆盖绝大部分需求的，就是这三个：git reset、git revert、git checkout。我习惯叫它们“git 回退版本三兄弟”。

这三个命令的核心目的都一样：让代码回到过去某个时间点的状态。但它们的工作方式、适用场景和对历史记录的影响完全不同。很多人只知道一个git reset --hard，打遍天下，结果在公共分支上把同事的提交全搞丢了，或者在本地一顿操作猛如虎，回头发现刚写的功能代码也跟着没了。这类事故我见得太多了。

所以这篇文章我不想只列命令参数，而是从“历史记录是怎么被改写的”这个底层视角出发，把三兄弟各自的定位、原理、适用场景和实操细节抠清楚。顺便把最近刷到的几个相关热词也串进去，比如 git checkout 与 git restore 的关系、git diff 在回退前怎么快速确认、--no-optional-locks 在脚本化操作里的作用等。把这些点串起来，你会发现 Git 回退其实是很直观的一套逻辑，前提是你脑子里得有那张“指针移动”的图。

先说结论：

• git reset：移动当前分支的 HEAD 指针，让分支“回到过去”，适合本地分支和尚未推送的提交。
• git revert：不移动指针，而是创建一个“反向提交”来抵消目标提交，适合公共分支和已推送的历史。
• git checkout（以及新版推荐的 git restore）：针对单个文件或工作区状态的“定点抢救”，适合还没提交、或者只想恢复某个文件的场景。

下面我一个个拆开讲，先把原理说透，再给你可复现的实操步骤。

2. 第一个兄弟：git reset，本地时间旅行机

2.1 理解 reset 前必须搞懂的三层状态

很多 Git 初学者搞不清楚 git reset 的三种参数，本质原因是没理解 Git 的三个存储区域：工作区、暂存区（Index）、版本库（HEAD 指向的提交）。这三者之间的关系你可以这样类比：工作区是你正在编辑的文档草稿；暂存区是你要交给老板审核的“定稿清单”；版本库是已经老板签字盖章、归档保存的最终版本。平时 git add 是把草稿加入待审核清单，git commit 是把清单里的内容正式归档。

git reset 干的活，就是把这次“归档”的状态往回拨，同时可以选择性地同步草稿和审核清单。它的完整命令格式是：

bash复制git reset --soft <commit>
git reset --mixed <commit>   # 默认模式
git reset --hard <commit>

--soft 最温柔：只把 HEAD 指针移动到指定提交，暂存区和工作区都不动。也就是说，你之前 git add 过的内容依然待在暂存区里，随时能重新提交。

--mixed 是默认行为：HEAD 指针移动之后，暂存区会被重置为指定提交的状态，但工作区文件不变化。这意味着你 git add 进去的内容会被“弹回”到工作区，变成未暂存状态，需要重新 git add。

--hard 最暴力：HEAD、暂存区、工作区三处全部重置。工作区里未提交的修改直接被丢弃，这个操作不可逆（严格说可以通过 reflog 找回，后面我会专门讲）。

理解这三档之后，reset 在你眼里就不再是“一个危险的命令”，而是“一把带三档调节的旋钮”，想拨到哪层就拨到哪层。

2.2 reset 实战：三种参数怎么选

假设你现在有这样的提交历史：

text复制A - B - C - D  (HEAD -> main)

你要回退到 B 这个提交。简单来说，就是让分支指针从 D 往回移动到 B。此时 A、B 之间的提交 C、D 就“悬空”了，但它们在 reflog 里仍然能查到。

场景一：提交完发现刚提交的内容有误，想重新提交。

这时候用 --soft 最合适：

bash复制git reset --soft HEAD~1

HEAD~1 表示当前提交的上一个提交。执行完这条命令后，分支指针退回上一个提交，但暂存区里还保留着你上一次 git add 的全部内容。你只需要改完代码，再 git commit 一次就行，不用重新 add。如果你提交信息写错了，这个方法也很有用。

场景二：不小心把不该提交的文件一起提交了，想撤销提交但保留工作区改动。

用默认的 --mixed：

bash复制git reset HEAD~1

执行后，上次提交的内容会全部回到工作区，变成未暂存状态。你可以重新挑选文件，git add 指定的文件，再提交一次。注意，这时修改仍然留在工作区里，不会丢。

场景三：本地写了一堆实验性代码，效果很差，想整体丢弃，回到某个干净版本。

果断 --hard：

bash复制git reset --hard <commit_id>

这条命令会把工作区、暂存区、HEAD 全部恢复到目标提交的状态。本地改过的文件全部被覆盖，新增文件会被清理。所以真正高危的不是 reset 本身，而是 --hard 对工作区的强制覆盖。

我自己在本地开发时最常用的节奏是：写完一块功能先 commit 一次打底，继续改别的，改到一半发现思路错了，直接 git reset --hard HEAD~1 回到打底版本重新来。只要这个提交还没有 push 到远端，本地怎么 reset 都没事。

2.3 reset 之后怎么找回“丢失”的提交

很多人一听 git reset --hard 就说“危险，会丢代码”。其实丢不丢，取决于你知不知道 reflog 这个救命稻草。Git 在每个本地仓库里都维护了一份操作日志，叫做 reflog。只要你操作过 Git（包括 reset、checkout、commit 等），在 reflog 里都能找到痕迹。

bash复制git reflog

输出大概是这样的：

text复制a1b2c3d HEAD@{0}: reset: moving to HEAD~1
e4f5g6h HEAD@{1}: commit: fix: 修复登录逻辑
...

如果你发现 git reset --hard 把原本提交的内容弄丢了，只需找到对应提交的 commit id，然后：

bash复制git reset --hard e4f5g6h

就能原地满血复活。reflog 默认保留 90 天，所以只要不是隔了太久，基本都能救回来。但注意，reflog 只存在于本地仓库，一旦你 git push -f 覆盖了远端，或者克隆了一个新仓库，reflog 里就没有这些记录了。所以本地纯玩怎么 reset 都行，牵扯到远端就一定要谨慎。