何为自律很多人在工作中没少被 git reset 坑过。前几天有个同事把开发分支上连着好几个 commit 一次性 --hard 回退掉，然后发现有一个 commit 里是他写了一下午的接口文档，整个人当场傻眼。虽然最后靠 reflog 把问题解决了，但那个下午的惊吓，加上周围一圈人围着命令行敲命令的场景，让我一直想写一篇把 Git Reset 四种模式真正讲透的文章。
Git Reset 表面上看只是"回退版本"，但它背后涉及的是 Git 最核心的存储区模型，而且 Soft、Mixed、Hard、Keep 这四种模式对三个存储区的处理方式完全不同，选错了轻则白干半天，重则代码直接人间蒸发。这篇文章我不会只给你背命令，而是把每种模式"为什么是这样"的机制讲明白，再用一个真实可复现的实验仓库，把四种模式跑一遍给你看，最后聊一聊日常开发中最该用哪种、最不该用哪种。
1. 先从一次"事故"讲清楚 Reset 究竟重置了什么
1.1 三个存储区的分工与联动
要理解 git reset 的四种模式，首要任务不是背参数，而是把 Git 的"三棵树"模型装进脑子里。所谓三棵树，其实就是三个存储区：
- HEAD：指向当前分支最近一次提交的指针，它代表的是"我最后一次提交时的项目快照"。
- Index（暂存区）：也就是
git add之后内容所在的位置，它是"我准备提交的下一个快照"。 - Working Directory（工作区）：你编辑器里正在操作的实际文件，它是"我当前正在修改的快照"。
我见过不少开发者对这三个区的理解停留在"暂存区就是中转站"的层面。实际上，Git 的日常操作本质就是在这三个区之间搬运内容：git add 把工作区内容复制到 Index，git commit 把 Index 内容固化成一个新的 commit 并让 HEAD 指针移动，git checkout 则是把 HEAD 中的内容往工作区方向铺开。
这三个区之间的关系，很像你在写一篇论文。
- 工作区是你的草稿纸，笔在上面随手写写画画；
- 暂存区是你挑选后的素材夹，你挑出一部分段落准备正式入稿；
- HEAD 是你已经排版印刷好的最近一版。
git reset 真正做的事情，就是以某个目标提交为基准，有选择地把这三个区"重置"到那个状态。选哪种模式，本质上就是在决定你愿意动到哪几棵树。
1.2 Reset 的底层动作：移动 HEAD、同步暂存区、同步工作区
很多人以为 git reset 是"删除提交"。这个理解在所有模式下都不够准确，尤其是对 --soft 模式来说，会产生严重的误导。准确地说，git reset 只是把 HEAD 指针移动到你指定的提交上，之前的提交对象本身还安安静静地躺在对象数据库里，只是没有分支引用它了而已。
整个 reset 过程可以拆解成三个独立动作：
- 移动 HEAD 指针到目标提交（四种模式都会做）。
- 决定是否用目标提交的内容覆盖暂存区 Index。
- 决定是否用目标提交的内容覆盖工作区文件。
不同模式的区别，就是这三个动作的组合差异。我画过一张比较直观的表格，先放在这里，后面我会逐个拆解：
| 模式 | 移动 HEAD | 重置 Index（暂存区） | 重置 Working Directory（工作区） | 核心安全级别 |
|---|---|---|---|---|
--soft |
是 | 否 | 否 | 最安全，改动全部保留 |
--mixed（默认） |
是 | 是 | 否 | 安全，已提交内容退回工作区 |
--hard |
是 | 是 | 是 | 危险，未提交的改动可能会被清掉 |
--keep |
是 | 是 | 条件性更新 | 相对安全，有冲突会直接中止 |
看到这个表的时候，你应该已经明白：reset 的四种模式并不是从"完全保留"到"彻底删除"的平滑过渡，而是一组对不同区域的选择性操作。Mixed 和 Keep 乍看只差一栏，但机制上的差异足以决定一个命令是"帮你保留现场"还是"直接把现场推平"。
1.3 一个快速判断模式的口诀
在进入细节前，我先给出一个我平时用来快速记忆的口诀，后面所有内容都围绕它展开：
Soft 只动指针，Mixed 动指针和暂存区，Hard 三区全动，Keep 相当于一个带冲突保护的 Hard。
这句话不严谨，但非常适合新手在命令行前面快速做判断。等你把机制彻底理解了，自然会发现 Keep 和 Hard 的关系远比"带冲突保护的 Hard"要微妙，那些细节我会在第四部分重点讲。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三种常见模式的机制拆解：Soft、Mixed、Hard
2.1 Soft：只搬 HEAD，变更原封不动送回暂存区
git reset --soft <commit> 是四种模式里动作最小的一种。它只移动 HEAD 指针，暂存区和工作区完全不做任何修改。举个非常日常的场景：你提交了一个 commit，写完 commit message 之后发现里面还包含了一个调试用的临时文件，你想把这个 commit 撤销掉，但保留所有文件变更，再重新精心挑选后提交。
此时 git reset --soft HEAD~1 执行完之后，你看到的状态是：刚才那次提交中涉及的所有文件变更，全都原封不动地出现在暂存区里，处于"已暂存（staged）"状态，就好像你刚执行完 git add 还没来得及 git commit 一样。你可以继续调整暂存内容，或者直接重新 git commit。
从数据流角度理解 --soft 是很有意思的。因为 HEAD 回退到了前一个提交，而 Index 还停留在"后一个提交"的内容状态，因此 git status 会认为"暂存区里有相对于 HEAD 的变更"，这些变更恰好就是被回退掉的那个提交所含的全部内容。它相当于一条传送带，把已经印好的那一版内容又退回素材夹里，纸张上的字一个没动。
--soft 还有一个被很多人低估的用法：处理"删掉最近几个 commit，但想把它们的变更合并成一个新的 commit"这种诉求。比如你把最近三个提交 HEAD~3..HEAD 合并成一个提交，git reset --soft HEAD~3 之后，三次提交的全部变更会叠加在暂存区里，直接 git commit 即可得到一个内容相同但历史干净的提交记录。
2.2 Mixed：默认模式，撤销暂存但保留现场
注意一个小细节：不写任何 mode 参数的 git reset，比如 git reset HEAD~1，等价于 git reset --mixed HEAD~1。也就是说，Mixed 是 git reset 的默认行为。很多人没有意识到这点，结果随手敲 git reset 想撤销 commit，行为却和他预期的 --soft 不一样。
--mixed 在移动 HEAD 的同时，会用目标提交的内容重置暂存区，但完全不动工作区文件。我用具体状态来解释：你 commit 了一次，然后执行 git reset --mixed HEAD~1，这个 commit 的变更就会从暂存区退回到工作区，变成"已修改未暂存（modified but not staged）"状态。
如果拿论文来类比：--soft 是把你印好的那一版拆散，所有段落回到"准备入稿"的素材夹；--mixed 是再进一步，把素材夹也清空，所有段落直接散落到桌面上，你需要重新一张一张地拣选到底哪些要放进下一版。
--mixed 最常见的应用场景是"撤销 add"。比如你 git add . 一股脑把一堆文件加进了暂存区，然后发现其中有几个不该加的文件。分支提交历史还没动的话，git reset（不带 commit）就能把暂存区清空，所有文件回到未暂存状态。在老版本 Git 里，这个操作还叫 git reset HEAD，后来有了更语义化的 git restore --staged，但 reset --mixed 仍然是最底层、最通用的机制。
需要注意的是，--mixed 不会因为你已经把某些文件在暂存后又手动修改过就产生特殊行为。它的逻辑是简单的：暂存区整体翻译成 HEAD 移动后的目标提交状态，而工作区文件保持原样，最终 git status 会自动计算出两者的差异。这也是为什么它在多数情况下是"最安全"的默认选项。
2.3 Hard：三区全回退，改动直接清空
git reset --hard <commit> 是四种模式里动作最大、也最容易造成事故的一个。它移动 HEAD、重置暂存区、同步工作区，一气呵成，最终效果是整个项目完全回到目标提交的状态，所有在目标提交之后做出的"已跟踪文件"修改，全部从工作区消失。
这里我必须加上一个非常关键的限定：--hard 会干掉的是已跟踪文件（tracked files）的本地修改，包括已经暂存的和未暂存的。但对于新创建的、从未被 Git 跟踪过的文件，它并不会主动删除。
这个细节特别重要。很多人在使用 --hard 后惊讶地发现某些新增的、还没有 git add 过的文件还在，产生"怎么没删干净"的困惑；反过来，也有人因为某个已跟踪配置文件被 --hard 重置，恨得咬牙切齿。
拿论文类比：--hard 就是把你草稿纸上的内容按已出版的版本重新抄一遍，桌上散落的段落、素材夹里的挑选结果全部作废，只留下出版物的最终内容。你改动过的草稿、写了一半的段落，如果之前没有存成独立文件，一瞬间就没了。
--hard 真正有价值的场景大概是这几类：
- 本地分支已经被改得面目全非，你想要彻底放弃所有本地改动，强硬对齐到远端分支，比如
git reset --hard origin/main。 - 做实验性改动，怎么折腾都不满意，想一键还原到实验开始前的状态。
- 合并冲突解决到一半，发现自己的策略完全错误，想回到合并前的起点重新来。
但我要强调，凡是涉及 --hard 的操作，都值得你多花两秒敲一个 git reflog 确认一下最后的提交哈希值，这会成为你"反悔"的唯一稻草。
3. Keep 模式：最冷门，也最容易被误解
3.1 Keep 的行为机制：带冲突保护的 Hard？
如果在网上搜 git reset 的四种模式，关于 --keep 的中文资料相对不多，而且不少表述会让你觉得它就是一个"更安全的 --hard"。这种说法大方向没错，但精度不够，容易在实际使用中产生困惑。
先看 Git 官方文档对 --keep 的行为描述（我意译一下）：
- 重置暂存区，并根据目标 commit 与当前 HEAD 之间的差异更新工作区文件。
- 如果目标 commit 与当前 HEAD 之间"有差异"的文件，在本地工作区也存在未提交的修改，那么 reset 会被中止，什么都不做。
翻译成人话就是：--keep 试图把工作区同步到目标提交的状态，但前提是——所有路径上涉及的文件，你本地都不能有未提交的改动。一旦你本地改动的文件正好撞上这次回退需要变更的文件，Git 会直接拒绝执行，而不是像 --hard 那样无声无息地把你的本地改动抹掉。
它和 --mixed 的区别在于：--mixed 完全不碰工作区，所以本地改动一定保留；--keep 会真的去更新工作区文件，但在更新过程中探测到冲突风险就立刻刹车。
它和 --hard 的区别在于：--hard 不管三七二十一，直接把你本地未提交改动全部覆盖清零；--keep 则会检查这些改动是否会被回退路径"压到"，会的话就中止操作，不会覆盖你的劳动成果。
3.2 Keep 与 Merge 模式的纠葛，以及一个重要的弃用提醒
可能有人听说过 git reset --merge（或 -m）这个模式。过去很长一段时间里，--merge 和 --keep 常被拿来对比。两者的核心区别是：
--merge：重置暂存区并更新工作区中在目标 commit 与 HEAD 之间发生变化的文件，但尽量保留你在本地做的未提交修改。如果本地修改与回退涉及的文件产生冲突，它会把冲突标记留在文件里，让你手动解决，而不是中止。--keep：遇到上面这种情况会直接中止整个 reset，不产生冲突标记。
需要特别提醒的是，--merge 模式已经被 Git 官方在 2024 年的 2.45 版本中正式标记为弃用（deprecated），计划在未来的某个大版本中移除。官方给出的理由也很直接：它的行为边界模糊，容易让使用者误判文件状态，且 --merge 支持的操作完全可以通过 --keep 加上 --stash 的组合来覆盖。所以如果你正在阅读的老教程里还在推荐 git reset --merge，请立刻把记忆更新为 --keep，不要在新版本上依赖一个注定消失的功能。
3.3 Keep 的实际使用场景
--keep 的适用场景，通常是你希望"在回退提交的同时，保留当前工作区里那些无关的本地修改"。
举个例子：你在分支上写了一半新功能，工作区里有几个文件处于改了一半的状态，此时你想把最近一次提交（commit A）回退掉——但前提是不能丢你现在改到一半的内容。如果 commit A 恰好修改了你正在手写的那几个文件，那么 --keep 会中止回退，告诉你先处理冲突；如果 commit A 只改了完全无关的文件，--keep 会顺利执行，你本地写了一半的东西原封不动。
这种"条件性保留"看起来很绕，但它的设计目标很明确：保证在任何情况下，本地未提交的改动都不会被 reset 偷偷覆盖，同时又能让工作区在无冲突时真正切换到目标提交的内容。这个特性在你频繁使用"临时提交（wip commit）"的工作流里尤其有用——我把当前半成品先提交给一个临时 commit，然后想在不丢掉半成品的条件下回退另一批提交，此时 --keep 是最合理的选择。
4. 用同一个实验仓库，把四种模式全部跑一遍
4.1 构造一个可复现的测试环境
理论讲再多，不如实际跑一遍。我建议你跟着下面的步骤，用命令行亲手搭一个实验仓库，几分钟就能彻底看懂四种模式的行为差异。
先打开终端，找一块临时目录，执行：
bash复制mkdir git-reset-lab
cd git-reset-lab
git init
# 配置用户信息（如果全局已配置可跳过）
git config user.name "demo"
git config user.email "demo@example.com"
然后我们创建第一个文件 app.js，内容是：
bash复制echo 'file - v1' > app.js
git add app.js
git commit -m "commit 1: 初始版本"
再改动一次，提交第二个版本：
bash复制echo 'file - v2' >> app.js
git add app.js
git commit -m "commit 2: 增加第二行"
最后再改一次，提交第三个版本：
bash复制echo 'file - v3' >> app.js
git add app.js
git commit -m "commit 3: 增加第三行"
此时 git log --oneline 应该看到类似这样的内容：
text复制a1b2c3d (HEAD -> master) commit 3: 增加第三行
e4f5g6h commit 2: 增加第二行
i7j8k9l commit 1: 初始版本
注意，我这里写的是示例哈希，你本地的哈希一定不同，后续操作请以你自己的实际哈希为准。为了方便，后面我统一用 HEAD~1 指向上一个提交，用 HEAD~2 指向上上个提交。
4.2 实测 Soft：变更回到暂存区
先执行：
bash复制git reset --soft HEAD~1
然后立刻运行 git status 和 git log --oneline 查看结果。
git log 中 commit 3 应该已经消失，HEAD 指到了 commit 2。而 git status 会告诉你：app.js 已经被修改，并且处于 Changes to be committed 状态，也就是暂存区里有相对于 HEAD 的改动。你还可以用 git diff --cached 看一下具体内容，会发现正是你在 commit 3 里加入的 file - v3 这一行。
这个模式下，工作区文件内容依然是三行，因为 app.js 文件的物理内容没有被改动，只是 Git 的状态记录认为它"等待下一次提交"。
4.3 实测 Mixed：变更退回工作区
在 soft 实验的基础上，继续执行：
bash复制git reset --mixed HEAD~1
此时 HEAD 又从 commit 2 回退到了 commit 1，暂存区被重置为 commit 1 的内容。再看 git status，app.js 的状态变成了 Changes not staged for commit，也就是"已修改未暂存"。工作区文件内容不变，依然包含三行。用 git diff 你可以看到对比的是"工作区 vs 暂存区/HEAD"的差异，显示出了后两行内容。
这个实验清晰地说明：--mixed 比 --soft 多动了一步——重置暂存区，而工作区的物理文件同样没有被改动。如果你想把改动再次放回暂存区，你需要重新 git add app.js。
4.4 实测 Hard：工作区被彻底重写
接着执行：
bash复制git reset --hard HEAD~1
执行的一瞬间，Git 会输出类似 HEAD is now at e4f5g6h commit 2: 增加第二行 的信息。这时候再打开 app.js 你会发现，文件内容只剩两行——file - v1 和 file - v2，你在 commit 3 中加的那一行物理上已经从工作区消失了。
这才是 --hard 真正危险的地方：它不只是改状态记录，而是直接重写工作区文件。如果文件中那些改动没有被提交过，也没有被 stash 过，那么这行内容就真的丢了（唯一的补救渠道是编辑器缓存，或者如果文件在某个时刻被 IDE 快照备份过）。
为了继续后面的实验，我们先把仓库恢复到一个稳定状态。既然工作区现在已经被重置成了两行，我们先重新补上第三行并提交为新的 commit：
bash复制echo 'file - v3' >> app.js
git add app.js
git commit -m "commit 3b: 第三行（重新添加）"
现在 git log --oneline 会看到 commit 3b 在顶部，和原先的 commit 3 内容几乎一样，但哈希值不同。
4.5 实测 Keep：冲突中止与顺利通过两种结果
现在演示 --keep 最核心的行为。先确保当前处于 commit 3b，然后我们在工作区对 app.js 做一个未提交的本地修改，但不能碰 commit 3b 相对于 commit 2 涉及的内容——因为 commit 3b 相对 commit 2 的差异就是在 app.js 上加了 file - v3 这一行，你一旦修改 app.js，本地未提交的改动就正好撞上了 reset 要更新的路径。
于是我们创建一个新文件 local-notes.txt 并在里面写点内容，模拟"本地未提交的、与回退路径无关的改动"：
bash复制echo 'local note' > local-notes.txt
然后执行：
bash复制git reset --keep HEAD~1
这次会成功。执行后，git log 显示 HEAD 回到了 commit 2，app.js 内容被更新为三行变成了两行（因为工作区确实被同步了），而 local-notes.txt 安然无恙地留在工作区。这个结果说明 --keep 确实会在确保不碰你本地改动的前提下，把工作区同步到目标提交。
接下来我们验证它的"中止"保护机制。先把 HEAD 恢复到包含 file - v3 的状态（当然，你可以用 git reset --hard ORIG_HEAD 或者直接 git reset --hard <commit 3b 的哈希> 把它找回来）。恢复后，直接编辑 app.js，手动加一行 echo 'local change' >> app.js。这相当于在工作区制造了一个"本地未提交改动"，而且这个改动位于 commit 3b 相对 commit 2 的差异路径上。
现在执行同样的命令：
bash复制git reset --keep HEAD~1
你会看到 Git 直接中止并报错，错误信息大致是：
text复制error: Your local changes to the following files would be overwritten by reset:
app.js
Please commit your changes or stash them before you reset.
这句话就是 --keep 的安全机制在起作用：它检测到工作区里有一个未提交的改动，而 reset 路径上恰好也要改这个文件，二者一旦相遇，你的本地改动风险极高，于是命令直接拒绝执行，给你留出处理余地。
此时你的工作区改动、暂存区状态、HEAD 位置完全没有任何变化，就像这条命令从没执行过一样。这是 --keep 和 --hard 最大的分水岭：--hard 遇到同样的情况会直接抹掉你本地改动并继续往前，--keep 则原地刹车。
5. 日常场景怎么选，以及三个容易踩的坑
5.1 场景与模式的速查表
实验做完，我们来谈更实际的问题：工作里到底什么时候用哪种模式。我把常见场景和推荐模式整理成了速查表：
| 目标 | 推荐模式 | 为什么 |
|---|---|---|
| 撤销最近一次提交，但保留改动以便重新暂存 | --soft |
改动留在暂存区，直接重新 commit 即可 |
| 撤销最近一次提交，且改动退回工作区慢慢处理 | --mixed（默认） |
暂存区被清空，工作区文件保留，最常用 |
| 放弃所有本地改动，强制对齐到目标提交/远端 | --hard |
三区全清，干脆彻底 |
| 撤销提交，但保留无关的本地未提交改动 | --keep |
冲突路径上自动中止，不会误伤本地修改 |
| 只撤销暂存、不撤销提交 | git restore --staged .（替代 reset --mixed 的部分场景） |
语义更清晰，Git 2.23+ 推荐 |
其中最让我担心的是那些"我以为只是撤回 add，结果把工作区也清了"的场景。你看这张表就能发现，--mixed 和 --hard 只差一个参数，但后果差了十万八千里。凡是想不清自己的工作区改动是否重要时，宁可先 git stash，再执行 reset，也别直接赌 --hard。
5.2 三个高频踩坑场景
第一个坑：误以为 reset --hard 会删除未跟踪文件。实际上它不会。如果你新建了一个文件从未 git add，--hard 不会碰它，这常常导致部署包、数据库备份这类敏感文件在 reset 后安然存在，反而让 Git 的"干净"变得不干净。如果你真想连未跟踪文件也清掉，需要 git clean -fd，请务必确认这个命令的杀伤范围再执行。
第二个坑：git reset 与 git checkout（或 git switch）的混淆。git checkout <commit> -- <file> 会用目标版本覆盖工作区文件，但不会移动 HEAD；git reset 则可能把整个分支引用给移动了。经常有同学想做"把某个历史文件提取出来"，却敲成了 git reset <commit>，把当前分支的 HEAD 给拽到了历史位置，后面的提交全不在分支图里了。好在还有 reflog 兜底，但这个惊吓没必要不断重演。
第三个坑：忽略 ORIG_HEAD 和 reflog 的救命价值。执行 git reset 之后，Git 会把原来的 HEAD 记录下来。ORIG_HEAD 可以在一些情况下帮助你快速撤销一次 reset，比如 git reset --hard ORIG_HEAD。不过最可靠的方式还是 git reflog，它会记录 HEAD 每一次变动，无论是因为 commit、checkout 还是 reset。找回丢失提交的完整路径就是：git reflog 找到丢失前的哈希，然后 git reset --hard <sha>。
5.3 说说我平时的工作流习惯
在写代码的这些年里，我实际使用频率最高的是 --mixed 和 --soft，--hard 只在确实想清楚后果时才用，而 --keep 反而是在做重构类任务时的大杀器。
具体来说，我维护一个长期功能分支时，经常用临时提交 wip 记录半成品。有一天想清理历史，把这些 wip 提交压平成一个正式提交时，我会在确认工作区干净后执行 git reset --soft，把一串 wip 提交的改动全部合并到暂存区，然后重新组织提交。这个流程几乎不会有风险，因为所有内容都已在之前的提交中固化了。
而 --hard 我只在执行"本地完全废弃当前状态、对齐远端"的场景使用，比如 git reset --hard origin/main。每次敲之前，我都会花几秒钟跑一下 git reflog 记住当前哈希。万一远端和本地本来就有细微差别，这个习惯能帮我迅速回到原点。
--keep 则出现在"我手头改了半天的文件没来得及提交，但老板让我先处理另一个紧急情况，需要回退一个已经提交的改动"这类场景。它不会让我临时改动意外蒸发，一旦路径冲突还会主动停下来让我决策，这是个人性化的选择。
最后再补一个小技巧：如果不确定某次 reset 会带来什么影响，最稳妥的办法是新建一个临时分支再执行。比如：
bash复制git branch backup/current
git reset --hard HEAD~5
这样即使 reset 后一切让你不满意，git switch backup/current 就能瞬间回到 reset 之前的状态。这个方法等于靠分支引用给 reflog 上了双保险，我建议每一个被 Git Reset 坑过的人，都把它记成条件反射式的习惯。毕竟 Git 给了我们这么强大的能力，怎么在快速操作的同时优雅地留好后路，才是真正区分经验深浅的地方。