git reset 大概是被误解最深的 Git 命令：有人把它当成"撤销神器"，一次误操作丢了三天的工作；有人谈之色变，宁可 git checkout 到处绕。其实 reset 的行为可以完全拆解成两个动作——移动分支指针与处理暂存区 / 工作区，把这两个维度想清楚，它就从"危险命令"变成精准的版本控制手术刀。本文从本质、三种模式、典型场景到常见误区，完整讲透 git reset。
1、本质：reset 只做两件事
Git 的三个区域是理解 reset 的前提：工作区（Working Directory，你正在编辑的文件）、暂存区（Index / Staging Area，git add 后的快照）、本地仓库（HEAD 指向的提交历史）。git status 输出的三个分区，正是这三者的差异对照。
在此之上，git reset 的行为可以拆解为两步：
- 移动当前分支指针：把分支指向指定的提交。这是"reset"名称的由来——重置的是分支位置，不是删除提交
- 按模式处理暂存区与工作区：决定移动指针之外，要不要连带重置暂存区（
--soft不动、--mixed重置暂存区、--hard暂存区与工作区全重置）
关键认知：被 reset"丢掉"的提交并没有立即消失。它们只是脱离了分支历史，变成悬空对象（dangling objects），在 Git 的垃圾回收（GC）真正清理前，仍然可以通过 reflog 找回。这一点是许多"reset 丢代码"惨剧的认知盲区，也是自救的底气。
2、三种模式：soft / mixed / hard
三个选项控制第二步的处理力度，一张表先立全貌：
| 模式 | HEAD（分支指针） | 暂存区 | 工作区 | 典型用途 |
|---|---|---|---|---|
--soft |
移动 | 不动 | 不动 | 撤销提交、保留改动 |
--mixed（默认） |
移动 | 重置 | 不动 | 撤销提交与暂存 |
--hard |
移动 | 重置 | 重置 | 彻底丢弃所有改动 |
2.1、--soft：只动指针
git reset --soft HEAD~1
分支指针回退一个提交，暂存区与工作区原封不动。效果是"撤销了提交，但所有改动完整保留且仍在暂存区"——你可以直接改完再 git commit 重新提交。
最典型场景：提交后发现少改了一个文件 / 写错了提交信息。与其 git commit --amend（只能改最后一次），reset --soft 可以回退任意多步再重新组织提交。
2.2、--mixed：指针加暂存区（默认）
git reset HEAD~1
# 等价于 git reset --mixed HEAD~1
分支指针回退，暂存区同步重置到目标提交的状态，但工作区不动。改动还在文件里，只是从"已暂存"退回"未暂存"。
典型场景：想把多个提交拆开重新组织，或 git add 错了文件想撤销暂存（git reset HEAD <file> 就是这个用法，git 2.23+ 后推荐用 git restore --staged <file> 替代）。注意 git reset（不带参数不带路径）只重置暂存区，不移动分支——这是它最安全的用法。
2.3、--hard：全重置
git reset --hard HEAD~1
分支指针、暂存区、工作区三者全部重置到目标提交。未提交的改动会被丢弃——这是唯一会真正覆盖工作区改动的模式，也是事故率最高的一种。
典型场景：本地实验性改动完全不要了，回到已知的干净状态。用前务必确认工作区没有还需要的东西。
一个直观对照（假设 HEAD~1 后有改动 A 已提交、B 已暂存、C 未暂存）：
git reset --soft HEAD~1 # 提交没了，A 在暂存区，B/C 不变
git reset --mixed HEAD~1 # 提交没了，A/B 都退回未暂存，C 不变
git reset --hard HEAD~1 # 提交没了，A/B/C 全部消失，工作区干净
3、reset 的参数语法
完整的命令形态是 git reset [<mode>] [<commit>]，另有一条路径形态 git reset [<commit>] -- <path>。
<commit> 的多种写法：
git reset --soft HEAD~3 # 当前位置往回 3 个提交
git reset --soft origin/main # 与远程分支对齐
git reset --soft <sha> # 任意提交的哈希
git reset --soft v2.1.0 # 标签
路径形态（不能配 --hard / --soft）：
git reset HEAD -- src/foo.py
# 把 src/foo.py 的暂存撤销，不影响分支指针与其他文件
路径形态下 reset 只动暂存区中对应文件，是最安全的用法之一；--hard 与路径不兼容（会报错），这也从侧面说明路径形态根本不涉及分支移动。
4、典型场景速查
4.1、撤销最近一次提交（保留改动）
git reset --soft HEAD~1
改动全部回到暂存区，修改后重新 git commit 即可。
4.2、把最近三次提交合成一次
git reset --soft HEAD~3
git commit -m "feat: 完整功能"
三次提交的改动全部进暂存区，一次提交收编。
4.3、撤销暂存（文件 add 错了）
git reset HEAD -- path/to/file
# 或现代写法
git restore --staged path/to/file
4.4、本地彻底放弃未提交的实验
git reset --hard HEAD
# 若还有未跟踪文件需要一并清理，追加
git clean -fd
4.5、reset 已推送的提交后强推
git reset --hard origin/main
git push --force-with-lease
--force-with-lease 比 --force 安全：若远程在你获取后被他人更新过，推送会被拒绝，避免覆盖别人的工作。
5、reset vs revert vs restore
三个"撤销"命令的分工经常被混淆，边界其实很清楚：
| 命令 | 改历史 | 影响远程 | 适用场景 |
|---|---|---|---|
reset |
是（本地） | 需强推 | 本地未推送的回退 |
revert |
否（新提交） | 正常推送 | 已推送的公共分支 |
restore |
否 | — | 只动工作区 / 暂存区文件 |
核心判断：提交是否已推送到共享分支。未推送——reset 自由操作；已推送——用 revert 生成反向提交，历史安全。
6、误操作自救：reflog
reset --hard 后悔了怎么办？reflog 记录了 HEAD 的每一次移动，包括 reset 造成的"脱离"。
# 查看 HEAD 的移动历史
git reflog
# 找到 reset 前的哈希，创建新分支找回或直接重置回去
git reset --hard <之前的哈希>
只要对象还没被 GC（默认 30 天 / 90 天），几乎总能找回。所以哪怕 reset 出错，第一步不是慌，是 git reflog。
7、总结
git reset 的本质是"移动分支指针 + 按模式处理暂存区与工作区"：--soft 只动指针（撤销提交、保留改动）、--mixed 动指针加暂存区（撤销提交与暂存）、--hard 三区全重置（彻底回退）；被丢弃的提交在 GC 前仍可经 reflog 找回。
实践建议按场景选型：撤销本地提交且保留改动——--soft；撤销暂存或拆分重组提交——--mixed（默认）；彻底放弃本地实验——--hard（用前确认工作区）；已推送的共享分支回退——改用 revert，不要 reset 加强推。掌握"指针移动 + 三区处理"这个心智模型后，reset 不再是危险命令，而是精准的版本控制工具。
