Git Reset 四种模式详解：从底层快照看透 soft/mixed/hard/keep

我先说一下现状：很多开发者天天在用 git reset，可一旦问起 --soft、--mixed、--hard 到底动了哪几层，就支支吾吾说不清。更别提 --keep 这个冷门选项，不少人都没听过。这非常可惜，因为 git reset 是工作区、暂存区、提交历史三者关系的核心枢纽，理解透了它，很多 Git 疑难杂症都会迎刃而解。

这篇文章不打算给你抄一堆命令了事，而是从 Git 底层文件快照的视角，把四种模式的机制、区别、适用场景一次讲透。整个过程有演示仓库、有实测输出、有恢复方案，看到最后你不仅能看懂 git reset --hard HEAD~1 背后到底发生了什么，还能在误操作之后冷静地把自己捞回来。

1. 理解 Reset 之前，先建立三个区的空间模型

很多教程一上来就列命令，结果读者只知道 --hard 能回退，不知道它把工作区也销毁了，踩坑之后才回头补概念。我的建议是，动手敲命令之前，先把 Git 的内部结构在脑子里立起来。

1.1 工作区、暂存区、版本库到底各存什么

Git 的日常操作本质上是在三个区域之间搬文件快照：

• 工作区（Working Directory）：你眼睛看到、编辑器里打开的那堆文件，就是你硬盘上的真实文件。
• 暂存区（Index / Staging Area）：git add 之后文件进入的地方。它存的不是文件实体，而是一个记录文件路径、权限、blob 对象 ID 的索引清单。
• 版本库（Repository / .git）：git commit 之后，暂存区的快照被永久写入 .git/objects 目录，成为一个个 commit 对象。

这三个区域的快照可能一致，也可能不一致。比如你刚打开仓库什么都没动，三者完全一致；你改了文件没 git add，工作区和暂存区不一致；你 add 了没 commit，暂存区和版本库不一致。git status 干的事情，本质上就是帮你比较这三者之间的差异。

1.2 Reset 的本质是移动 HEAD 指针和同步快照

git reset 的单词 "reset" 容易让人联想到"删除"或"清空"，但它的核心动作其实只有一个：把当前分支的 HEAD 指针移动到指定的提交。

只不过，指针移动之后，另外两个区域要不要跟着变，就由模式参数来决定了。Git 官方文档对 git reset 的描述是：

Reset current HEAD to the specified state.

这句话信息量很大。"current HEAD" 指的是当前分支顶端的提交，"specified state" 是你给定的目标提交。reset 之后，你等于把整个分支的时间线拉回到了过去或挪到了某个其他提交上。

要理解这个动作，可以把 commit 历史想象成一条由玻璃珠子串成的链，每个珠子上贴着一张代码快照，当前所在的位置用一根红色箭头（HEAD）指着。git reset 就是你用手把箭头从当前位置拔下来，插到链条的另一个位置上去。至于你手里拿着的"代码文件副本"（工作区、暂存区）要不要一起变，取决于你选哪种模式。

注意：reset 只是移动了指针，并不会立即删除任何提交对象。被 reset 掉的那些提交仍然存在于 .git/objects 中，直到被 Git 的垃圾回收机制（gc）清理。理论上，只要你知道 commit 的哈希值，就能把它们找回来。这一条是后面所有恢复操作的理论基础，务必记住。

1.3 一个类比，彻底区分三种默认行为

为了更好理解，我常用一个生活化类比：

想象你正在写一本纸质书（工作区），草稿纸上写好的段落（暂存区），最终印刷成册的版本（版本库）。

• --soft：你重新定义了"最新印刷版"是哪一版（HEAD 移动了），但草稿纸和书稿内容都没动。所有被跳过的内容还整整齐齐摆在暂存区里，等你重新梳理。
• --mixed：你不仅重新定义了最新印刷版，还把草稿纸上的标注全部清空了（暂存区重置），但你在原稿上的手写修改都还在（工作区不变），相当于回到"还没 add 但已经改过文件"的状态。
• --hard：你直接把最新印刷版、草稿纸、以及原稿全部撕掉重来（三个区全部对齐到目标提交），所有未提交的改动当场消失。

这三个模式的差别不是"删不删历史"，而是"指针移动后，暂存区和工作区要不要同步移动到目标提交的状态"。理解这一点，比背任何命令都有效。

2. 四种模式逐一拆解：机制、参数、适用场景

Git 的 reset 家族一共有四个成员：--soft、--mixed（默认）、--hard、--keep。前三个大家比较熟悉，最后一个 --keep 相对冷门，但它在特定场景下非常有用。

2.1 Soft 模式：只移动指针，一切改动原地待命

git reset --soft <commit> 的语义非常单纯：把 HEAD 移动到目标提交，暂存区和工作区一律不动。

假设当前 HEAD 在 commit C，暂存区和工作区都有一些未提交的改动。执行 git reset --soft HEAD~1 之后，指针回到 commit B，但暂存区仍然是原来的状态，工作区的修改也原封不动。此时你执行 git status，会看到所有在 C 中提交过的文件都处于"已暂存"状态，而且你之前在暂存区做的其他变更也在。

这个模式最适合一个场景：你刚刚提交了一个 commit，但马上发现少加了文件，或者提交信息写错了、提交内容分错了。正常思路是先 git reset --soft HEAD~1，把提交撤销回暂存区，然后补充文件、修改暂存内容、重新 commit。整个过程不会碰你工作区里任何一行代码，非常安全。

我自己的使用习惯是：--soft 几乎只用于"撤销上一