1. 问题场景
你刚完成了一次提交，信心满满地觉得新版本没问题。几分钟后，测试跑不过，或者你突然意识到这个修改方向根本是错的。你想立刻回到上一个正常的版本继续工作，仿佛这次提交从没发生过。这时候，就需要 Git 的版本回退功能------这台"时光机"让你可以精准降落到过去任何一个提交节点。
2. 核心概念
在动手之前，先理清几个关键名词。
2.1 HEAD
HEAD 是一个指针，始终指向你当前所在分支的最新一次提交。你可以把它理解为"当前所处的位置"。绝大部分回退操作，本质上就是移动这个指针。
2.2 git log
git log 用来查看提交历史。每一次提交都有唯一的 commit id（一个长长的哈希值）、作者、日期和提交说明。不带参数时，会列出完整信息；加上参数可以让输出更紧凑，方便快速定位。
2.3 git reset
git reset 是执行回退的主要命令。它能把 HEAD 指针以及相关区域恢复到指定的历史提交。根据参数不同，它的作用范围也不同，直接影响你当前的工作成果。
2.4 git reflog
git reflog 记录了你在本地仓库中每一次移动 HEAD 的操作历史，不管是 commit、reset、还是 checkout 切换分支。即使你回退之后 git log 里已经看不到某些提交，reflog 依然会忠实地记录它们，是你"反悔"后重返未来的救命稻草。
3. 核心命令
先整体列出涉及的几个主要命令，后面会用实战场景具体演示。
bash
# 以单行精简格式显示提交历史
git log --pretty=oneline
# 回退版本（三种模式）
git reset --hard <commit-id> # 工作区、暂存区、版本库全部回退
git reset --mixed <commit-id> # 回退版本库和暂存区，工作区不变
git reset --soft <commit-id> # 只回退版本库，暂存区和工作区不变
# 查看 HEAD 移动记录（操作历史）
git reflog4. 实战演示
我们用上一篇的 myproject 仓库继续练习。如果你还没有这个仓库，可以新建一个并先做几次提交。
4.1 制造几个提交，模拟历史
进入仓库，往 ReadMe 文件里逐次追加内容并提交：
bash
$ cd myproject
$ echo "version1" >> ReadMe
$ git add ReadMe
$ git commit -m "add version1"
$ echo "version2" >> ReadMe
$ git add ReadMe
$ git commit -m "add version2"
$ echo "version3" >> ReadMe
$ git add ReadMe
$ git commit -m "add version3"现在仓库里已经有了三次有顺序的提交。
4.2 查看提交历史
用精简格式看一下：
bash
$ git log --pretty=oneline
d95c13f (HEAD -> master) add version3
14c12c3 add version2
cff9d1e add version1输出按照时间倒序排列，最新提交在最上面。(HEAD -> master) 表明当前 HEAD 指向 master 分支的最新提交 d95c13f。你的 commit id 会不同，后面操作时请替换成你自己的。
4.3 回退到上一个版本
现在发现 version3 是错的，想回到 version2 的状态。执行：
bash
$ git reset --hard 14c12c3
HEAD is now at 14c12c3 add version2--hard 参数让工作区、暂存区、版本库全部回退。此时查看文件内容：
bash
$ cat ReadMe
hello git
hello git again
version1
version2version3 那行已经消失了，完全恢复到 version2 提交时的样子。
再次看日志：
bash
$ git log --pretty=oneline
14c12c3 (HEAD -> master) add version2
cff9d1e add version1d95c13f 那一条已经看不到了。
4.4 反悔了，想回到未来
如果你回退之后又后悔了，想恢复 version3，不能用 git log 去找，因为它已经不显示了。这时候轮到 git reflog 登场：
bash
$ git reflog
14c12c3 HEAD@{0}: reset: moving to 14c12c3
d95c13f HEAD@{1}: commit: add version3
14c12c3 HEAD@{2}: commit: add version2
cff9d1e HEAD@{3}: commit: add version1reflog 记录了每一次 HEAD 的移动。可以看到 d95c13f 还在这里，它就是那个 add version3 的提交。再次用 reset --hard 回去：
bash
$ git reset --hard d95c13f
HEAD is now at d95c13f add version3ReadMe 中 version3 又回来了。这就是"时光机"能双向旅行的原理：git log 看的是提交关系链，git reflog 看的是你的本地操作历史。只要 commit id 没被垃圾回收，你总能找回来。
4.5 使用 HEAD^ 快捷方式
除了 commit id，还可以用 HEAD^ 或 HEAD~1 表示"上一个版本"，HEAD^^ 表示上两个版本，以此类推。例如回退到上一版：
bash
$ git reset --hard HEAD^这在日常使用中更快捷。但注意，HEAD^ 是相对于当前的位置，如果你已经处于一个比较旧的状态，继续用 HEAD^ 就会回到更老的版本。
5. 三种 reset 模式对比
git reset 支持三种模式，区别在于对工作区和暂存区的影响不同。当你不是用 --hard 时，回退只是移动指针，不会丢弃当前修改。
| 模式 | 版本库 (HEAD) | 暂存区 (Stage) | 工作区 (Working Directory) |
|---|---|---|---|
--soft |
回退 | 不变 | 不变 |
--mixed (默认) |
回退 | 回退 | 不变 |
--hard |
回退 | 回退 | 回退 |
--soft：HEAD 回退，暂存区和工作区内容都保留。相当于把这次提交拆掉，但所有改动都在暂存区里，可以重新修改后再提交。适用于只想修改提交说明或者重新组织提交。--mixed：HEAD 和暂存区都回退，工作区保留。改动从暂存区里撤出，回到"未暂存"状态。相当于撤销了git add和git commit。这是git reset不加参数时的默认行为。--hard：全部回退，工作区也被覆盖。所有未提交的修改都会被永久丢弃。⚠️ 使用前务必确认工作区没有需要保留的内容。
一个典型的应用场景：刚提交完发现漏了一个文件，或者提交说明写错了，可以用 --soft 回退，然后重新 add、commit。如果想连暂存区的状态也撤销，就用 --mixed。如果确认这次提交完全是垃圾，不想留任何痕迹，才用 --hard。
6. 注意事项
git reset --hard是破坏性操作，它会清空工作区所有未提交的修改。执行前务必用git status确认工作区是干净的，或者已做好备份。- 即使用了
--hard，只要通过git reflog还能找到旧的 commit id，通常可以恢复。但如果执行了git gc或超过了 Git 的垃圾回收期（默认30天），未引用的提交可能被真正删除，就找不回来了。 - 如果已经推送到远程仓库，不建议对已推送的提交做
reset，除非你清楚这是在改写公共历史。多人协作中，回退公共历史会制造混乱。正确的做法是使用git revert（后续会讲）。 - commit id 很长，实际操作中不需要全部输入，通常取前 5-7 位就够了，Git 会自动匹配。
7. 要点总结
git log查看提交历史，git reflog查看本地操作历史，后者是真正的后悔药。git reset --hard <commit>让你回到任意历史版本，但会丢弃工作区改动。--mixed和--soft提供了更温和的回退方式，保留工作内容，适合修正提交。- 快捷方式
HEAD^、HEAD~n让回退更方便。 - 回退前一定确认工作区状态，避免数据丢失。
8. 练习题
- 创建一个新仓库，连续做 3-5 次提交，每次修改
ReadMe或创建新文件。 - 使用
git log --pretty=oneline查看提交记录，然后用git reset --hard回到第 2 个版本。 - 用
git reflog找到最新那个版本的 commit id，再用git reset --hard恢复回去。 - 分别练习
--soft和--mixed回退，观察git status和git log的变化，理解它们的区别。 - （思考题）如果你想撤销刚刚提交的
add version3，但又希望改动保留在工作区，应该用哪种 reset 模式？试着操作并验证。