先把结论撂这儿：git reset是我见过被误解最深的 Git 命令，没有之一。
我遇到过不少同事，把git reset当"后悔药"用，结果一吃就吃过头，把别人提交的代码也一块儿抹了；也有人把git reset跟git revert当成一回事，在共享分支上随手一敲，然后整个团队的仓库就开始"灵异事件"。这些问题我在刚开始用 Git 的那两年全踩过，所以想系统地把git reset讲透，从原理、三种模式到实际场景里的正确姿势，顺便把我用 reflog 捞回误删提交的完整过程分享出来。这篇东西适合所有刚装好 Git、正在学命令行的朋友，也适合那些已经用了一阵子但一遇到reset就发怵的开发者——看完你能明白它到底在"重置"什么，以及什么场景该用它、什么场景用了会出事儿。
1. 先搞明白一件事：reset到底在"重置"什么
好多教程上来就给你列命令参数，--soft、--mixed、--hard背得滚瓜烂熟，但遇到真实场景照样懵。原因很简单：你根本不理解 Git 里的状态是什么，自然不知道"重置"两个字动了谁的奶酪。
1.1 我的Git三层模型理解
我一直跟新同事说，学 Git 千万别急着背命令，先把下面这三层搞明白：
- 第一层：Working Directory（工作区），就是你电脑上肉眼能看到的那些文件和文件夹，改代码就是改这里。
- 第二层：Index / Staging Area（暂存区），是个"待提交清单"。你用
git add把文件放进去，相当于告诉 Git：这批改动我准备好了。 - 第三层：Repository（本地仓库），也就是你提交之后历史记录保存的地方，HEAD 指针就指在这个仓库里当前分支的最新提交上。
这三个概念，我用一个收拾行李的类比来解释：工作区是你的房间，四处堆着东西；暂存区是你手里的行李箱，你决定哪些衣服要带走，就往里塞；本地仓库是已经封箱、贴上标签、记在账本上的行李记录。提交一次git commit，就是"封了一个箱并记了账"。
git reset这个命令，本质上是个"指针搬运工"——它把 HEAD 指针（以及可选地，把暂存区、工作区）移动到指定的提交位置。它并不像大多数人以为的那样"删除"了什么东西，而是让分支的指针退回到过去某一点，让你仿佛回到了那个时刻。
1.2 reset与"回滚"的差别
这里必须拉一个非常重要但一直被忽视的概念：git reset和"撤销、回滚"不是同一件事。
我见过很多文章把 reset 翻译成"版本回退"，这个说法能让人理解个大概，但也非常害人——它会让你以为 reset 像游戏读档一样，把世界恢复到某个存档点，后面发生的一切都消失了。实际上，reset 只是移动了分支指针，至于暂存区和工作区是否跟着动，完全取决于你选择哪种模式。
更重要的是，git reset改写的是"分支引用的指向"，它会改变提交历史。原本位于指针后面的提交不会马上被物理删除，它们会在 reflog 里躺上一段时间（默认 90 天），如果你需要，完全可以捞回来。这一点在后面第 5 章我会详细演示。
所以你在用 reset 之前，脑子里先得有一个明确的图景：我到底是只想让 HEAD 指针挪一挪，还是想连暂存区里的东西也清空，或者干脆连工作区的代码也一起丢掉？这个问题的答案，直接对应下面要讲的三种模式。
2. 三种模式：--soft、--mixed、--hard 到底动了几层
git reset最让人头疼的地方，就是它的三个参数--soft、--mixed、--hard。背起来容易，但真到了实战，你得清楚地知道：每一层模式动了三层状态中的哪几层。
先给出一张我压箱底的对照表，我每次教新人都先甩这张表：
| 模式 | HEAD指针（当前分支） | 暂存区（Index） | 工作区（Working Tree） | 典型用途 |
|---|---|---|---|---|
--soft | 移动 | 不动 | 不动 | 想重新提交，保留所有改动为"已暂存"状态 |
--mixed（默认） | 移动 | 随目标提交重置 | 不动 | 撤销git add，保留工作区修改 |
--hard | 移动 | 重置 | 重置为指定提交内容 | 彻底丢弃所有改动，强制回到某提交 |
这张表如果你能印在脑子里，reset 的用法基本就掌握了一半。接下来逐个拆解。
2.1 --soft：只挪动HEAD指针
git reset --soft <commit>的工作是：把 HEAD 指针挪到目标提交，但暂存区和工作区都保持原状。也就是说，你的所有改动依然处于"已暂存但未提交"的状态。
打个比方：你本来已经封好了一个行李箱（已提交），现在想拆开重新整理（因为发现漏了东西），但你又不想把已经收进去的衣服全部拿出来摆回房间。--soft相当于只撕掉箱子上的标签，箱子里的东西保持原样，你随时可以再封一次箱子。
这个模式在我实际工作中最高频的使用场景是整理提交历史。比如你连续提交了 5 次，但发现它们其实应该合成 1 次提交，这时候就可以：
git reset --soft HEAD~5 git commit -m "合并起来的全新提交信息"这一套操作下来，5 个提交的改动全都被"浓缩"进暂存区，然后一次性提成交。干净利落，而且不会丢任何代码改动。
2.2 --mixed（默认模式）：撤销暂存
不带参数的git reset就等于git reset --mixed，前提是你给了目标位置；如果你只敲git reset不带任何提交目标，它会默认把暂存区重置到 HEAD，这正好是撤销git add的最快方法。
--mixed做的事情是：移动 HEAD 指针，同时把暂存区的内容重置成目标提交的状态，但是不动工作区。也就是说，你git add过的那些文件，会重新变回"已修改但未暂存"的状态，但你改的代码内容还在，不会丢。
我最常用的一个场景：
# 不小心把不该提交的文件 add 进来了 git add 敏感配置文件 git reset # 刚才的 add 被撤销，敏感文件回到未暂存状态注意，git reset后面如果不接任何参数，含义是"把暂存区重置为当前 HEAD"，所以它等价于git reset --mixed HEAD。这条命令非常安全，不会丢代码，我建议每个 Git 新手都把它当成肌肉记忆练熟了。
2.3 --hard：最危险，但也最干脆
git reset --hard <commit>是三位一体全重置：HEAD、暂存区、工作区全部重置到目标提交的状态。这意味着你工作区里未提交的改动、暂存区里准备好的内容，全都说拜拜了。
从收拾行李的类比来看，--hard就是"把箱子全拆了，房间里的东西也按照指定时间点的样子重新摆，所有后来的变动一律不留"。这个命令一旦执行，你工作区里那些没提交的代码基本就悬了（后面我会讲 reflog 怎么捞，但相信我，不是每次都能百分百捞回来）。
那为什么还要用它？因为有些场景确实需要"物理级别的干净"。比如你在一个实验分支上把代码改得面目全非，想彻底放弃，回到远端同步时的状态：
git reset --hard origin/main这个东西我在清理本地过期分支时经常配合使用，能够快速把一个分支恢复到远端一模一样的样子。但前提是，你得确定自己真的不想要工作区里那些改动了。
2.4 三者选型的判断思路
在讲具体场景前，我先把选择思路交给你，这样遇到新情况也能自己判断：
- 只是想重新组织提交记录，不想碰任何代码改动 →
--soft - 想撤销暂存操作（
git add），但保留工作区改动 →--mixed - 想让代码、暂存区、HEAD 三者完全同步到某个状态，彻底丢弃改动 →
--hard
我个人还有一个经验：拿不准的时候，先用--soft或--mixed，绝不用--hard试错。--hard的信息丢失风险太高，而 reset 本身已经能覆盖绝大多数"后悔"需求；如果真需要硬重置，我会先看一眼 reflog 里有没有最近的记录，心里有个底再动手。
3. 什么时候该用哪种模式：我的实操场景复盘
光讲原理不够，我把日常开发里最常见的几个 reset 场景拆开复盘一下，每个都对应实际项目里会遇到的状况。
3.1 场景一：commit 写错了想重新提
你刚提交完，突然发现自己漏了一个文件，或者 commit message 打错了一个字。这种"轻微后悔"需求，很多人第一反应是git reset --hard HEAD~1，然后重新提交——这个操作不仅危险，还容易把刚写的改动一起丢了。
正确做法有两种路：
路线 A，提交还没有推到远端，只是本地提交错了：
# 修正最近一次提交的信息 git commit --amend -m "修正后的提交信息" # 如果有漏掉的文件，先补进暂存区 git add 漏掉的文件 git commit --amend --no-edit路线 B，如果你不是想改最后一次提交，而是想改更早的几次提交，或者想把 2 个提交合并成 1 个，这时候才轮到 reset：
git reset --soft HEAD~2 git add . git commit -m "合并为一条新提交"注意我在这里用的是--soft，不是--hard。因为我想保留工作区和暂存区里已经写好的代码改动，只是把"提交历史"重新揉成一团。这个操作在提交历史还没推到远端时可放心用。
3.2 场景二：git add 多了文件想撤回
这种情况几乎每周都发生：git add .手一滑，把不该提交的编译产物、本地配置、日志文件都加进来了。处理方式我相信你已经会了：
git reset不带参数，默认--mixed，直接把暂存区清回 HEAD 状态，工作区改动原地保留。然后再用git add精挑细选，只提交真正需要的内容。
如果只想撤销某一个文件，而不是全部：
git reset -- 某个文件/目录的路径这个命令会把指定路径从暂存区撤出来，不影响其他已经在暂存区里的内容。善用git reset -- <path>这种带路径的形式，比git reset全量撤回要精细得多。
3.3 场景三：本地改乱了想彻底放弃
我之前有个习惯：喜欢在本地拉一个实验分支随便改，改崩了就回到主分支。这个场景下，我确实需要用--hard：
# 先看当前分支状态 git status # 切换回目标分支，并强制重置到远端最新状态 git checkout main git fetch origin git reset --hard origin/main这里有一个我踩过的坑：如果有未提交的改动，git checkout main可能会失败或者把改动带过去（具体取决于文件冲突情况）。所以最稳妥的顺序是先确认git status，实在不行先git stash暂存改动，再 reset。
但请记住，--hard是"核弹级别"的操作。我用它之前会养成了一个习惯：先看一眼 git log，确认自己要回到的提交是否真的是想要的点。比如你本意是回到HEAD~3，结果看错了回退到更早的地方，那就非常尴尬了。
3.4 场景四：想移动分支起点至某个老提交
这是什么场景呢？比如你发现某个功能分支是在一个很旧的主分支上拉出来的，现在想把它的"基底"挪到主分支最新的提交上，让它包含主分支最近的所有更新。
这在 Git 里可以用rebase来做，但很多人也会选择用 reset 完成类似的效果：
# 把当前功能分支的指针，先移到最新主分支上（但不碰工作区） git reset --soft main这个操作会把 HEAD 指向 main 的最新提交，同时保留你所有改动的暂存状态，看起来就像"功能分支重新基于 main 生长"。不过说实话，这里面细节比看着的复杂，我更推荐老老实实学git rebase，reset 这种用法更像"土方法"。
4. reset 和 revert、checkout 的区别，为什么总有人搞混
说句不好听的，Git 几个"撤销"相关命令的命名是真反人类：reset、revert、checkout看起来都能让代码"变回去"，但背后的行为逻辑完全不一样。我把它们拉一张表对着看：
| 操作 | 作用对象 | 对历史记录的影响 | 关键判定 |
|---|---|---|---|
git reset | HEAD、暂存区、工作区（取决于模式） | 改写本地历史，移动分支指针 | 适合本地未推送的提交 |
git revert | 工作区、历史记录 | 新增一个反向提交，旧提交保留 | 适合已推送的公共分支 |
git checkout | HEAD、工作区（可作用于分支或文件） | 通常不改变历史，只是切换 | 适合切换分支/恢复文件 |
4.1 为什么不要在共享分支上 reset
这是我最想说的一点。
假设你和同事一起在dev分支上干活，你本地做了 3 个提交，推上去了，同事拉下来继续改。这时候你发现第 1 个提交有个大 bug，于是你本地一个git reset --hard HEAD~3，把本地指针挪回推送之前的状态，然后git push --force强推上去。这在表面上"成功"了，但同事那边的仓库还留在旧历史上。下一次他提交代码后，一拉远端，直接出现分叉，Git 根本不知道你的 reset 是"有意"的——你们俩的历史再也无法自动合并，只能靠手动rebase互相伤害。
我见过不止一次因为push --force导致团队开发进度连续乱掉的情况，所以这里立一个原则：
原则：
git reset只适合重置尚未推送的提交。如果提交已经推到了共享分支，请改用git revert。
4.2 revert：保留历史的"反向提交"
git revert <commit>做的事情是，创建一个新的提交，这个提交的内容是把目标提交的改动反向应用回去。比如你提交了"新增了 A 功能"，revert 之后会生成一个"删除 A 功能"的提交，但原来的提交还留在历史里。
这个特性在团队协作里是救命的：因为历史没有变，同事拉取代码时会正常合并，不会出现"历史分叉然后互相打架"的情况。
git log --oneline --graph # 假设有个不想要的提交 abc1234 git revert abc1234这样会弹出一个提交信息编辑窗口，默认写好了 Revert 信息，确认即可。整个远端历史是一条安静的直线，谁看了都舒服。
4.3 checkout 和 reset 的模糊地带
再说git checkout。它和reset确实有功能重叠的地方：
git checkout <branch>：切换分支，同时更新工作区的文件内容，但它不会动暂存区（其实是切换分支时暂存区会被清空，但切换前后暂存区内容不能带过去）。git checkout -- <file>：把工作区里某个文件恢复成暂存区/HEAD 里的版本，相当于"丢弃工作区对某个文件的修改"。
这个用法和git reset --hard有一点像，但 reset 是全量、不可精确到单个文件，而checkout -- <file>是精准打击单个文件。还有一个我常用的区分方法：
- 改动了暂存区 → 用
git reset - 只想丢弃工作区某个文件 → 用
git checkout -- 文件名
所以你可以把 reset 理解为"作用于整个分支状态的【回退】"，checkout 理解为"切换分支 / 精准恢复文件"的工具。两者各管一摊，不要混用。
5. 核心经验：reset 之后如何反悔（reflog 救场）
虽然我前面反复强调--hard危险，但真到了实战，每个人总会有手滑的时候。我至今记忆犹新的一个事故是这样的：
有一次我在一个功能开发分支上干活，连续提交了好几次。当时想整理一下提交历史，本来打算用--soft把最近 3 个提交合并成 1 个，结果闭着眼睛敲成了git reset --hard HEAD~3。等我睁开眼，工作区里所有待提交的改动全没了，提交记录也退回到了 3 个提交之前，整块功能直接蒸发。
我当时的心情不用多形容。但接下来我要讲的这个救命稻草，让我在十分钟内把现场完整地捞了回来。
5.1 reflog 是什么
Git 的 HEAD 每次发生变化，都会被记录在一个叫 reflog（reference log，引用日志）的地方。无论你是 commit、reset、checkout、merge，还是 cherry-pick，所有"HEAD 移动"都有痕迹。这个日志默认在仓库的.git/logs/HEAD文件里，通过git reflog直接查看。
关键点在于：reset 不会立刻清空 reflog。所以哪怕你reset --hard把 HEAD 挪走了，被甩在身后的那些提交还在 reflog 里躺着，等着你去"认领"。
5.2 完整恢复流程演示
假设我发生了上面那个事故，恢复步骤是这样的：
# 1. 查看 HEAD 的移动历史 git reflog # 输出可能长这样 # abc1234 HEAD@{0}: reset: moving to HEAD~3 # def5678 HEAD@{1}: commit: 完成功能C # ...在 reflog 里，HEAD@{1}的位置就是发生 reset 之前的状态，那一行的 commit 哈希，就是我要找回的提交点。
# 2. 直接使用 reflog 中看到的哈希进行恢复 git reset --hard def5678这一下，HEAD、暂存区、工作区全部回到了"reset 之前"的状态，我那个功能分支就像什么都没发生过一样。虽然虚拟内存中丢失的东西不一定每次都能完美恢复，但绝大多数未提交很久的改动，只要还没有被 Git 的垃圾回收机制清理掉，这个方法都非常可靠。
这里有个细节想特地强调：如果你是想找回工作区里的未提交改动，但你又已经执行了--hard，难度就大很多。因为未提交的内容不会出现在 提交里，自然也不会出现在 reflog 里，能捞回来的概率很低。所以我有一个死规矩：执行--hard之前，如果看到git status有未提交的改动，先git stash或者复制一份出去。
5.3 通过 reflog 找回被误删的提交
还有另一个高频场景：你用git reset --hard删掉了一个已经提交但还没推远端的提交。这种情况下，提交本身是完整的，只要知道哈希，随时都能用git reset --hard <hash>或者git cherry-pick <hash>把它找回来。
# 查看 reflog，找到被删掉的提交哈希 git reflog | grep "完成功能" # 用 cherry-pick 把这个提交重新应用回当前分支 git cherry-pick def5678cherry-pick的好处是，它不会改变你当前分支的指针位置，只是把你指定的提交"复制"到当前分支上来，生成一个新的提交。当你不想整体回退、只想捞回某一次提交时，这是一个比 reset 更精细、更安全的选择。
6. 团队协作中 reset 的禁区与建议
最后聊聊团队协作里那些跟 reset 相关的"规矩"和"习惯"。这些经验是我在多人协作项目中一点一点攒出来的，希望对你有参考价值。
6.1 已推送分支的硬性红线
第一条红线我之前已经反复铺垫过：绝对不要对已经推送到远端并被其他人拉取过的分支执行git reset之后强推。这会让所有同事的本地仓库联合崩溃，你的"悔棋"会变成别人的"惊悚片"。
那如果你发现自己刚推了一个包含敏感信息（比如密码）的提交怎么办？正确的做法不是 reset，而是：
git revert <那个提交>同时用filter-branch或filter-repo对历史进行清理（这个操作更复杂，且需要全团队配合），然后再推送。revert 至少保证团队成员能正常合并、正常开发，不会立刻引发冲突风暴。
6.2 未推送自己的分支：reset 的舒适区
我不否认 reset 在个人分支、本地提交整理时有奇效。特别是在下面这些场景，reset 用起来得心应手：
- 想把本地多个提交压缩成一个，并保持提交历史整洁
- 想放弃本地最近几次提交，回到远端同步点重新开始
- 想临时调整本地分支起点
在这些场景下，只要分支还没有被推送，或者你非常确定只有你在用这个分支，那么 reset 就是高效且安全的工具。
6.3 区分"reset"与"pull --rebase"
多说一句和 reset 相关的协作命令：git pull --rebase。当你本地的提交和远端分叉时，rebase会把你本地的提交一个一个"摘下来"，放到远端提交之后重新应用。这和 reset 没有直接关系，但它背后的核心机制也是"移动提交"，所以很多人会搞混，把它当成"我可以用 reset 消除分叉"。
其实如果本地分叉了，正确做法是：
git fetch origin git rebase origin/main而不是git reset --hard origin/main——后者会直接丢掉你本地所有提交，前者是保留你的工作成果，只是重新排一下顺序。这两个命令的区别，我在一次加班到凌晨的排错中领悟得特别深刻，现在每次都会提醒身边的人。
6.4 reset与commit --amend的关系
既然热搜词里有人问git commit --amend，我顺带提一下它和 reset 的同族关系。其实：
git reset --soft HEAD~1 git commit -m "新的提交信息"和直接：
git commit --amend -m "新的提交信息"做的事情高度相似——都是把最后一次提交的指针撤回来重做。区别是amend不会移动 HEAD 指针，而是原地修改最后一次提交的内容；reset --soft HEAD~1会把 HEAD 指针挪走，再重新提交一个新提交。从提交历史快照来看，两者产生的最终文件状态一样，但 reflog 里的记录会不同。
我的建议是，只改最近一次提交时优先用amend，需要重组的提交数量超过一个时，才考虑 reset。
6.5 不想追的坑位：关于--keep和--merge
其实 git reset 还有两个不常被提及的参数，--keep和--merge。它们的目的是在不丢失未提交改动的前提下移动 HEAD 指针。这类参数在界面上看起来挺有用，但实际场景里成功率不高，因为底层逻辑对文件冲突非常敏感，出问题的概率不小。除非你已经熟悉 Git 内部机制，否则我不建议日常开发中把时间花在这上面，扎实掌握 soft/mixed/hard 三个已经够熟了。
最后再分享一个小技巧，是我现在每个项目都会遵守的习惯：在敲git reset --hard之前，先敲一个git stash或者git diff > /tmp/my-changes.patch备份当前改动。这多花十秒钟，却能让你在误操作之后有机会"起死回生"。我自己就是从一次差点丢尽代码的事故里学乖的——现在 my-changes.patch 文件已经成了我工作目录里的常客，偶尔还会真的派上用场。
