Git基本操作（三）：版本回退，坐上“时光机”

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. 核心命令

先整体列出涉及的几个主要命令，后面会用实战场景具体演示。

# 以单行精简格式显示提交历史
git log --pretty=oneline

# 回退版本（三种模式）
git reset --hard <commit-id>    # 工作区、暂存区、版本库全部回退
git reset --mixed <commit-id>   # 回退版本库和暂存区，工作区不变
git reset --soft <commit-id>    # 只回退版本库，暂存区和工作区不变

# 查看 HEAD 移动记录（操作历史）
git reflog

4. 实战演示

我们用上一篇的 myproject 仓库继续练习。如果你还没有这个仓库，可以新建一个并先做几次提交。

4.1 制造几个提交，模拟历史

进入仓库，往 ReadMe 文件里逐次追加内容并提交：

$ 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 查看提交历史

用精简格式看一下：

$ 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 的状态。执行：

$ git reset --hard 14c12c3
HEAD is now at 14c12c3 add version2

--hard 参数让工作区、暂存区、版本库全部回退。此时查看文件内容：

$ cat ReadMe
hello git
hello git again
version1
version2

version3 那行已经消失了，完全恢复到 version2 提交时的样子。

再次看日志：

$ git log --pretty=oneline
14c12c3 (HEAD -> master) add version2
cff9d1e add version1

d95c13f 那一条已经看不到了。

4.4 反悔了，想回到未来

如果你回退之后又后悔了，想恢复 version3，不能用 git log 去找，因为它已经不显示了。这时候轮到 git reflog 登场：

$ 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 version1

reflog 记录了每一次 HEAD 的移动。可以看到 d95c13f 还在这里，它就是那个 add version3 的提交。再次用 reset --hard 回去：

$ git reset --hard d95c13f
HEAD is now at d95c13f add version3

ReadMe 中 version3 又回来了。这就是"时光机"能双向旅行的原理：git log 看的是提交关系链，git reflog 看的是你的本地操作历史。只要 commit id 没被垃圾回收，你总能找回来。

4.5 使用 HEAD^ 快捷方式

除了 commit id，还可以用 HEAD^ 或 HEAD~1 表示"上一个版本"，HEAD^^ 表示上两个版本，以此类推。例如回退到上一版：

$ 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. 练习题

1. 创建一个新仓库，连续做 3-5 次提交，每次修改 ReadMe 或创建新文件。
2. 使用 git log --pretty=oneline 查看提交记录，然后用 git reset --hard 回到第 2 个版本。
3. 用 git reflog 找到最新那个版本的 commit id，再用 git reset --hard 恢复回去。
4. 分别练习 --soft 和 --mixed 回退，观察 git status 和 git log 的变化，理解它们的区别。
5. （思考题）如果你想撤销刚刚提交的 add version3，但又希望改动保留在工作区，应该用哪种 reset 模式？试着操作并验证。

---