【Git】从入门到精通（十一）—— git reset 三种模式详解

一、git reset 的作用

在深入三种模式之前，我们先搞清楚 git reset 到底在做什么。

git reset 的核心作用是：移动 HEAD 指针和当前分支指针 ，并可选地影响暂存区和工作区。

回顾一下 Git 的三大区域：

工作区（Working Directory）：你正在编辑的文件，也就是磁盘上能看到的内容。
暂存区（Staging Area / Index） ：git add 后进入的区域，即将被提交的内容。
版本库（Repository） ：git commit 后形成的提交历史，HEAD 指针指向当前分支的最新提交。

git reset 可以把当前分支指针"倒退"到某个历史提交，并根据模式决定是否同步刷新暂存区和工作区。正因为如此，它常被用来：

撤销最近的一次或多次提交
把暂存区的内容撤回到工作区（取消 git add）
彻底丢弃最近的修改（危险操作）

理解 git reset 的关键在于：它操作的是"指针的移动"，而不是"创建新提交" 。这与后面要讲的 git revert 有本质区别。

二、三种模式对比（本篇核心）

git reset 有三种主要模式，由参数 --soft、--mixed、--hard 控制。它们的区别在于：移动 HEAD 之后，是否重置暂存区、是否重置工作区。

2.1 三种模式一览

模式	HEAD/分支指针	暂存区	工作区	说明
`--soft`	移动	不变	不变	只撤销 commit，修改仍保留在暂存区
`--mixed`（默认）	移动	重置	不变	撤销 commit 和 add，修改保留在工作区
`--hard`	移动	重置	重置	彻底撤销，修改全部丢失（危险！）

2.2 用一张图理解

假设当前状态是：工作区、暂存区、HEAD 三者一致，都指向提交 C2。

复制代码

执行前：
工作区  ──┐
暂存区  ──┼──► C2 (HEAD)
历史    ──► C1 ◄── C2

执行 git reset HEAD~1（回退到 C1）后，三种模式的结果：

复制代码

--soft :   工作区=C2内容, 暂存区=C2内容, HEAD=C1  （修改"跑"到暂存区）
--mixed:   工作区=C2内容, 暂存区=C1内容, HEAD=C1  （修改"跑"到工作区）
--hard :   工作区=C1内容, 暂存区=C1内容, HEAD=C1  （修改彻底消失）

记住这张对比表，下面我们逐一详解。

三、每种模式详解

3.1 git reset --soft HEAD~1：撤销 commit，保留暂存

--soft 是"最温柔"的模式：只移动 HEAD 指针，暂存区和工作区都不动。

适用场景 ：你刚提交了一次 commit，但发现 commit 信息写错了，或者想再补充一些文件到这次提交里。用 --soft 撤销 commit，文件改动还在暂存区，可以直接重新提交。

完整演示：

复制代码

# 假设当前有两个提交
$ git log --oneline
c3a1b2d (HEAD -> main) 第三次提交
b2f4e8a 第二次提交
a1d9c7f 第一次提交

# 工作区、暂存区都是干净的
$ git status
On branch main
nothing to commit, working tree clean

# 现在用 --soft 回退一个提交
$ git reset --soft HEAD~1

# 查看日志，最新提交变成了"第二次提交"
$ git log --oneline
b2f4e8a (HEAD -> main) 第二次提交
a1d9c7f 第一次提交

# 查看状态：第三次提交的改动还在暂存区！
$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   index.html

# 可以直接重新提交
$ git commit -m "第三次提交（修正信息）"
[main d4e5f6g] 第三次提交（修正信息）
 1 file changed, 1 insertion(+)

可以看到，--soft 撤销了 commit，但改动仍然停留在暂存区，随时可以重新 git commit。

3.2 git reset --mixed HEAD~1：撤销 commit 和 add，保留修改

--mixed 是默认模式（不写参数就是它）。它会移动 HEAD，并把暂存区重置到目标提交的状态，但工作区的文件改动保留。

适用场景 ：你想撤销最近一次 commit，并且把文件改动从暂存区"撤回"到工作区（相当于同时撤销了 git add 和 git commit），然后重新组织要提交的内容。

完整演示：

复制代码

# 当前状态
$ git log --oneline
c3a1b2d (HEAD -> main) 第三次提交
b2f4e8a 第二次提交
a1d9c7f 第一次提交

# 用 --mixed 回退（不写参数等同 --mixed）
$ git reset HEAD~1
Unstaged changes after reset:
M       index.html

# 日志回退了
$ git log --oneline
b2f4e8a (HEAD -> main) 第二次提交
a1d9c7f 第一次提交

# 状态：改动在工作区，但不在暂存区
$ git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   index.html

# 需要重新 git add 才能提交
$ git add index.html
$ git commit -m "重新组织后的第三次提交"

与 --soft 的区别就在这里：--mixed 把改动"踢"出了暂存区，你需要重新 git add。

3.3 git reset --hard HEAD~1：彻底撤销，修改也丢失

--hard 是"最暴力"的模式：移动 HEAD，同时把暂存区和工作区都重置到目标提交的状态。所有未提交的修改都会丢失，无法通过常规方式恢复。

适用场景：你确信最近的几次修改完全不要了，想彻底丢弃，回到一个干净的历史状态。

完整演示：

复制代码

# 当前状态
$ git log --oneline
c3a1b2d (HEAD -> main) 第三次提交
b2f4e8a 第二次提交
a1d9c7f 第一次提交

# 用 --hard 回退
$ git reset --hard HEAD~1
HEAD is now at b2f4e8a 第二次提交

# 日志回退
$ git log --oneline
b2f4e8a (HEAD -> main) 第二次提交
a1d9c7f 第一次提交

# 工作区也干净了，改动彻底消失
$ git status
On branch main
nothing to commit, working tree clean

警告：--hard 会丢失工作区中所有未提交的改动。执行前请务必确认这些改动真的不需要了。如果误操作了，可以尝试用 git reflog 找回（见后文安全提醒）。

四、git reset 回退到指定提交

除了用 HEAD~1、HEAD~3 这种相对引用，还可以直接指定提交哈希。

4.1 回退到指定提交

复制代码

# 查看历史，找到想回退到的提交
$ git log --oneline
e5f6g7h (HEAD -> main) 第五次提交
d4e5f6g 第四次提交
c3a1b2d 第三次提交
b2f4e8a 第二次提交
a1d9c7f 第一次提交

# 回退到"第三次提交"
$ git reset --hard c3a1b2d
HEAD is now at c3a1b2d 第三次提交

$ git log --oneline
c3a1b2d (HEAD -> main) 第三次提交
b2f4e8a 第二次提交
a1d9c7f 第一次提交

4.2 回退到远程状态

有时候本地分支被改得乱七八糟，想直接和远程保持一致：

复制代码

# 先获取远程最新
$ git fetch origin

# 把本地 main 重置到远程 main 的状态
$ git reset --hard origin/main
HEAD is now at f7g8h9i 更新README

这个操作会丢弃本地所有领先于远程的提交和未提交修改，慎用。

五、git reset ：取消暂存单个文件

git reset 还有一个很常用的用法：取消暂存单个文件 ，相当于 git reset --mixed HEAD <file>。

复制代码

# 误把两个文件都 add 了
$ git add index.html style.css

$ git status
On branch main
Changes to be committed:
        modified:   index.html
        modified:   style.css

# 只想把 style.css 撤出暂存区
$ git reset style.css

$ git status
On branch main
Changes to be committed:
        modified:   index.html
Changes not staged for commit:
        modified:   style.css

这个用法只影响暂存区，不动 HEAD，也不动工作区文件内容。新版 Git 推荐用 git restore --staged <file> 替代，但 git reset <file> 依然广泛使用。

六、实战场景

场景1：commit 消息写错了

复制代码

$ git commit -m "修复登录bug"   # 哎呀，其实是修复注册bug

# 用 --soft 撤销，改动还在暂存区
$ git reset --soft HEAD~1

# 重新提交，写正确的消息
$ git commit -m "修复注册bug"

也可以直接用 git commit --amend，但 reset --soft 更通用。

场景2：多个提交合并为一个

你连续提交了三次，其实都是同一个功能的零碎改动，想合并成一个提交：

复制代码

$ git log --oneline
c3 (HEAD) 补充注释
b2 修复 typo
a1 实现功能X

# 回退3个提交，但保留所有改动在暂存区
$ git reset --soft HEAD~3

# 一次性提交
$ git commit -m "实现功能X"

这样三条零碎的提交就变成了一条干净的提交。

场景3：彻底放弃最近几次修改

复制代码

# 最近两次提交都是错误尝试，全部丢弃
$ git reset --hard HEAD~2

执行前务必三思，必要时先 git branch backup 备份。

场景4：把分支重置到远程状态

复制代码

$ git fetch origin
$ git reset --hard origin/main

常用于本地分支和远程冲突太多，干脆放弃本地、以远程为准。

七、reset 的安全提醒

git reset --hard 会丢失数据，这是 Git 中最容易"翻车"的操作之一。几点提醒：

执行 --hard 前先 git status，确认工作区没有未保存的重要改动。
不确定就先备份 ：git branch backup-$(date +%s) 创建一个备份分支，reset 后发现不对还能切回来。
误操作后用 reflog 找回 ：Git 会记录 HEAD 的所有移动轨迹，即使 reset --hard 了，提交对象在一段时间内仍然存在。

查看 reflog

$ git reflog
c3a1b2d HEAD@{0}: reset: moving to HEAD~1
e5f6g7h HEAD@{1}: commit: 第五次提交
d4e5f6g HEAD@{2}: commit: 第四次提交

发现 reset 错了，想回到"第五次提交"

$ git reset --hard e5f6g7h

注意：reflog 只能恢复已经 commit 过的提交 ，工作区中未提交的改动一旦被 --hard 清掉就真的没了。

7.1 reflog 恢复完整演示

下面演示一次"误操作 → 恢复"的完整过程：

复制代码

# 当前有3个提交
$ git log --oneline
c3a1b2d (HEAD -> main) 添加用户列表
b2f4e8a 添加登录页面
a1d9c7f 初始化项目

# 误操作：想丢弃最近一次，结果多打了个~2
$ git reset --hard HEAD~2
HEAD is now at a1d9c7f 初始化项目

# 发现不对，两个提交都没了！
$ git log --oneline
a1d9c7f (HEAD -> main) 初始化项目

# 别慌，用 reflog 查看 HEAD 的移动历史
$ git reflog
a1d9c7f HEAD@{0}: reset: moving to HEAD~2
c3a1b2d HEAD@{1}: commit: 添加用户列表
b2f4e8a HEAD@{2}: commit: 添加登录页面
a1d9c7f HEAD@{3}: checkout: moving from feature to main

# 找到误操作前的状态 c3a1b2d，恢复
$ git reset --hard c3a1b2d
HEAD is now at c3a1b2d 添加用户列表

# 验证，提交都回来了
$ git log --oneline
c3a1b2d (HEAD -> main) 添加用户列表
b2f4e8a 添加登录页面
a1d9c7f 初始化项目

reflog 是 Git 的"后悔药"，但要注意它有保留期限（默认 90 天），超期后提交可能被 git gc 清理。所以发现误操作后要尽快恢复，不要拖几个月。

7.2 用 ORIG_HEAD 快速恢复

每次 reset 前，Git 会把原来的 HEAD 位置存到 ORIG_HEAD。如果刚 reset 完就后悔了：

复制代码

$ git reset --hard HEAD~3
# 立刻后悔了

# 一键恢复
$ git reset --hard ORIG_HEAD

比翻 reflog 更快，但只对最近一次 reset 有效。

八、git reset vs git revert

这两个命令都能"撤销修改"，但原理完全不同：

对比项	`git reset`	`git revert`
原理	移动指针，改变历史	创建一个"反向"新提交
历史	会改写提交历史	历史不变，新增提交
已推送	不建议对已推送的分支用	安全，适合公共分支
冲突	一般无冲突	可能产生冲突

简单记：reset 是"假装没发生过"，revert 是"做一个撤销操作" 。团队协作中，对已经 push 到远程的提交，应该用 revert 而不是 reset。revert 会在后续文章详讲。

九、常见问题 FAQ

Q1：git reset 和 git reset HEAD 一样吗？ 一样。HEAD 是默认值，git reset 等同 git reset --mixed HEAD，常用来清空暂存区。

Q2：HEAD~1 和 HEAD^ 有区别吗？ 基本一样，都表示"上一个提交"。HEAD~2 表示上两个，HEAD^^ 也表示上两个。但在涉及合并提交时 ^ 可以指定第几个父提交，如 HEAD^2。

Q3：reset --hard 后提交真的永远消失了吗？ 默认 reflog 保留 90 天，期间可通过 git reflog 找回。超过保留期会被 git gc 清理。

Q4：能 reset 到未来的提交吗？ 不能。reset 只能往历史方向移动指针。要"前进"用 git checkout 或 git reset --hard <更新的commit>。

Q5：reset --soft 后暂存区和 HEAD 不一致，正常吗？ 正常。这正是 --soft 的特点：HEAD 倒退了，但暂存区还保留着原来的内容，所以 git status 会显示一堆待提交的改动。

Q6：git reset 能撤销 merge 吗？ 能。合并后 ORIG_HEAD 指向合并前的状态，git reset --hard ORIG_HEAD 即可撤销合并。如果是三方合并，--soft 或 --mixed 也能撤销但会把合并的改动留在暂存区/工作区。

Q7：reset --hard 和 checkout 有什么区别？ checkout <commit> 会进入"分离 HEAD"状态（不在任何分支上），不改变分支指针。reset --hard <commit> 会移动当前分支指针到目标提交。checkout 是"我去看看"，reset 是"分支搬过去"。

Q8：能 reset 到另一个分支吗，如 git reset --hard feature？ 能。这会把当前分支指针移动到 feature 指向的提交，工作区也变成 feature 的内容。常用于"放弃当前分支的改动，完全以 feature 为准"。

十、最佳实践

优先用 --soft 或默认模式 ，只在确信要丢弃改动时才用 --hard。
--hard 前先备份 ：git branch backup 只花一秒钟，能救命。
不要对已推送的公共分支用 reset 改写历史 ，用 revert 代替。
撤销单个文件暂存用 git reset <file> 或 git restore --staged <file> ，不要用 --hard。
合并零碎提交用 reset --soft HEAD~n + 重新 commit，比逐个 amend 更灵活。
养成看 git status 的习惯，清楚三大区域的当前状态再决定用哪种模式。
误操作后第一时间用 reflog，不要慌张地继续操作，越操作越难恢复。
reset 到远程前先 fetch ，确保 origin/main 是最新的，否则可能回退到旧状态。

十点五、三种模式速查与决策指南

10.5.1 一句话区分三种模式

--soft："我只想改 commit 信息或重新组织提交，改动一个都不丢。"
--mixed："我想撤销 commit 并把改动撤回工作区，重新选择要 add 什么。"
--hard："这些改动我通通不要了，给我一个干净的状态。"

10.5.2 决策流程

复制代码

想撤销提交？
├── 改动还要吗？
│   ├── 要，且想重新提交 → reset --soft
│   ├── 要，但想重新组织 → reset --mixed（默认）
│   └── 不要了，全丢弃 → reset --hard
└── 不想撤销提交，只想撤出暂存区？
    └── reset <file> 或 restore --staged <file>

10.5.3 常见操作对照速查

我想做什么	用什么命令
撤销最近1次commit，改动留暂存区	`git reset --soft HEAD~1`
撤销最近1次commit，改动留工作区	`git reset HEAD~1`
彻底丢弃最近1次commit和改动	`git reset --hard HEAD~1`
撤销最近3次commit，合并为一个	`git reset --soft HEAD~3` 然后 commit
把某文件撤出暂存区	`git reset <file>`
清空整个暂存区	`git reset`
回退到指定提交	`git reset --hard <hash>`
和远程保持一致	`git reset --hard origin/main`
误操作后恢复	`git reset --hard <reflog哈希>`

十一、小结

git reset 是 Git 中功能强大但需要谨慎使用的命令。核心记住三点：

--soft：只移 HEAD，改动留在暂存区 → 适合"重新提交"。
--mixed（默认）：移 HEAD + 清暂存区，改动留在工作区 → 适合"重新组织提交"。
--hard：移 HEAD + 清暂存区 + 清工作区 → 适合"彻底丢弃"。

配合 git reflog 兜底，即使误操作也有机会挽回。下一篇我们将讲解 git rm 与文件删除的相关操作，敬请关注。

下一篇：【Git】从入门到精通（十二）------ git rm 与文件删除

【Git】从入门到精通（十一）—— git reset 三种模式详解

一、git reset 的作用

二、三种模式对比（本篇核心）

2.1 三种模式一览

2.2 用一张图理解

三、每种模式详解

3.1 git reset --soft HEAD~1：撤销 commit，保留暂存

3.2 git reset --mixed HEAD~1：撤销 commit 和 add，保留修改

3.3 git reset --hard HEAD~1：彻底撤销，修改也丢失

四、git reset 回退到指定提交

4.1 回退到指定提交

4.2 回退到远程状态

五、git reset ：取消暂存单个文件

六、实战场景

场景1：commit 消息写错了

场景2：多个提交合并为一个

场景3：彻底放弃最近几次修改

场景4：把分支重置到远程状态

七、reset 的安全提醒

查看 reflog

发现 reset 错了，想回到"第五次提交"

7.1 reflog 恢复完整演示

7.2 用 ORIG_HEAD 快速恢复

八、git reset vs git revert

九、常见问题 FAQ

十、最佳实践

十点五、三种模式速查与决策指南

10.5.1 一句话区分三种模式

10.5.2 决策流程

10.5.3 常见操作对照速查

十一、小结