黄小秋自打用上 Git 的第一天起，我们几乎都躲不开 git reset。它是最常用的回退命令，同时也是最容易被误解、误用的命令之一。尤其当看到 --soft、--mixed、--hard 和前几年不那么常见的 --keep 这四种模式摆在一起时，很多人第一反应是“用 hard 就行了”“soft 是啥？有什么用”。我今天想把这四种模式的机制、区别和实际使用场景一次性讲透，并且用一个真实可复现的示例仓库，带你看清每种模式到底动了什么。
如果在排错、整理提交历史、撤销误操作时，你能准确猜到 git reset 每一种模式会带来什么状态，你对 Git 的理解会上升一个台阶。这篇文章适合刚学会 commit 的新手，也同样适合已经被 reset 坑过几次、想真正搞清楚的开发者。读完你可以直接照着敲，把结果和预期对照一遍，比死记命令选项有用得多。
1. Reset 之前，必须先搞懂 Git 的“三棵树”
1.1 三个区域，而不是一个目录
很多 Git 教程喜欢说 Git 是“快照式版本管理”，但对初学者来说，最直观的理解其实是：Git 维护着三个不同的“区域”，你的每一个命令都在调整这三个区域之间的差异。这三个区域分别是：
- 工作区（Working Directory）：就是你电脑里实际看到的文件目录，能被编辑器直接编辑的那一层。
- 暂存区（Index / Staging Area）：可以理解成一个中间缓冲区，
git add之后，修改会被记录到这里，但还没有成为正式提交。 - 版本库（HEAD / Repository）：已经提交的记录，
git commit之后内容进到这里，HEAD 指向当前分支的最新提交。
为什么把这三个区域叫“三棵树”？因为在 Git 内部，这三者各自都对应一棵“文件树”（tree object），记录着某个时刻所有文件的路径、内容和权限信息。git reset 最核心的作用，就是在这三棵树之间做“指针搬移”和“内容重置”。
1.2 理解“HEAD 指针”和“分支指针”
在聊 reset 的四种模式前，我们必须先建立另一个关键认知：分支名本质上只是一个指针，指向某个提交（commit）。HEAD 则是一个“当前在哪”的指针，它通常指向某个分支名，而分支名再指向具体的提交。
git reset <commit> 做的事，通俗说就是“把当前分支的指针强行挪到 <commit> 位置”。但挪动指针之后，暂存区和工作区要不要跟随变化，恰恰就是 --soft、--mixed、--hard、--keep 这些选项分道扬镳的起点。
这个理解非常重要，因为它解释了为什么 git reset 除了撤销提交，还能用于合并多个提交、拆分提交、清空暂存区等场景。它不是单纯“删历史”，而是“让当前分支起点重新定位”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 四大模式逐个拆解：它们各自动了什么
2.1 --soft：只移动 HEAD，暂存区和工作区全部保留
git reset --soft <commit> 的运行效果是：只把分支指针和 HEAD 移动到目标 commit，暂存区（Index）和工作区（Working Directory）都保持原样，一个文件都不动。
换句话说，执行完 --soft 之后，你之前提交的内容会“原封不动”地变成暂存区里的待提交内容。你可以直接理解为：刚执行了 git commit，但想反悔，于是用 --soft 回退，所有改动仍然停在暂存区，等你重新组织提交。
什么时候用它？最常见的场景是“我提交得太早了，想把最近几次提交合并成一个，或者改一下提交信息”。比如你连续提交了三次“WIP”内容，想合并成一次像样的提交，就可以 git reset --soft <最早那次提交的前一个>，然后重新 git commit。因为所有改动都还在暂存区，不会丢失任何工作。