一、git reset 的作用

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

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

回顾一下 Git 的三大区域：

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

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

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

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

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

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

2.1 三种模式一览

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 中最容易"翻车"的操作之一。几点提醒：

1. 执行--hard前先git status，确认工作区没有未保存的重要改动。
2. 不确定就先备份：git branch backup-$(date +%s)创建一个备份分支，reset 后发现不对还能切回来。
3. 误操作后用 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

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

简单记：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 为准"。

十、最佳实践

1. 优先用--soft或默认模式，只在确信要丢弃改动时才用--hard。
2. --hard前先备份：git branch backup只花一秒钟，能救命。
3. 不要对已推送的公共分支用 reset 改写历史，用revert代替。
4. 撤销单个文件暂存用git reset <file>或git restore --staged <file>，不要用--hard。
5. 合并零碎提交用reset --soft HEAD~n+ 重新 commit，比逐个 amend 更灵活。
6. 养成看git status的习惯，清楚三大区域的当前状态再决定用哪种模式。
7. 误操作后第一时间用 reflog，不要慌张地继续操作，越操作越难恢复。
8. 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 常见操作对照速查

十一、小结

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

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

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

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