遇见高中生遇到“撤销上一次提交”这个需求，说明你已经开始真正使用 Git 了，而不是停留在 add、commit、push 三连。但麻烦在于，网上关于这个问题的回答经常把人绕晕：有人说用 git reset --hard，有人说用 git revert，还有人直接甩一句“git push --force 覆盖一下”。命令本身都没错，可一旦用错场景，轻则改动白丢，重则把同事刚推上来的代码覆盖掉。这篇文章就把 git reset 和 git revert 这两条路彻底拆开讲清楚，覆盖撤销 commit、撤销 push 的完整操作流程，再顺带解决几个我平时答疑时被反复问到的高频报错。不管你是刚开始用 Git 的新手，还是已经接手团队分支的协作开发者，这里给到的判断逻辑和命令组合都能直接落地上手。
1. 先分清撤销场景：代码还没离开本地，和已经被别人看见，是两套玩法
动手之前，先回答一个问题：你要撤销的那个提交，是否已经 push 到远程仓库？在你 push 之后，有没有其他人拉取过这个分支？这两个答案直接决定你该用 git reset 还是 git revert，也决定你能不能安全地执行 git push --force。我见过太多人在本地提交错后直接对远程强推，最后把同事的分支搞乱，本质上就是没先判断提交的“可见范围”。
1.1 提交的“可见范围”决定命令选择
Git 里的提交一旦推到远端，就不再是你一个人的事了。别人 pull 下来之后，你的本地历史和其他人的本地历史就会产生依赖关系。基于这个前提，我把日常场景分成三类，每一类的处理方式完全不同。
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 只提交，未 push | git reset |
远端没有任何记录，本地历史可以随意改写 |
| 已 push，但只有自己在用这个分支 | git reset + git push --force-with-lease |
没有其他人依赖，覆盖后影响可控 |
| 已 push，并且多人共享或已合入主干 | git revert |
保留完整提交历史，避免协作者本地仓库分叉 |
很多人纠结 reset 和 revert 哪个好，其实它们不是竞争关系，而是处理不同场景的工具。简单记一句话：reset 是“反悔了，想重来”，revert 是“已经公开，不能改，只能补一个反向提交”。这条原则在团队协作里能避免九成的事故。
1.2 动手前花十秒确认两件事
我自己的标准动作是：任何撤销操作之前，先跑两条命令。
bash复制git log --oneline -5
git status
第一条命令是为了看目标提交的位置和哈希值。比如输出里最上面一条是 abc1234 fix: 增加登录功能，那 HEAD 当前就指在这个提交上，撤销它可以直接用 HEAD~1，也可以直接用 abc1234 这种完整哈希。第二条命令是为了确认工作区干不干净。如果工作区还有一堆未提交改动，你又准备用 git reset --hard，那后果就是这些改动全部被清掉，而且 reset 之后不一定能恢复。
所以我的建议是：不确定自己工作区内容是否重要时，先执行 git stash 把改动暂存起来，再开始撤销操作。等撤销完成，确认没问题了，再 git stash pop 把改动放回来。这一招花不了两秒钟，但能避免很多“撤销完发现刚才的改动全没了”的惨案。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. git reset：本地提交回退的首选，三种模式对应三种“清理深度”
git reset 是处理本地提交最顺手的工具。它做的事情简单说就是：把当前分支的指针移动到指定提交位置。移动之后，原来那个“最新提交”就不再被分支指向了，看起来就像被撤销了。但关键是，移动之后你原来提交里的改动去哪里，这就是 --soft、--mixed、--hard 三种模式的区别。
2.1 三种模式差别在哪
| 模式 | 效果 | 适用场景 |
|---|---|---|
--soft |
撤销 commit，保留改动到暂存区（index） | 提交完发现漏了文件，想补进同一个提交 |
--mixed（默认） |
撤销 commit 和暂存，保留改动到工作区 | 提交完想重新整理，重新 add |
--hard |
撤销 commit，并丢弃所有改动 | 提交内容彻底不要了，回到干净状态 |
拿一个具体例子来说。假设你刚执行了：
bash复制git commit -m "feat: 新增用户模块"
然后发现少 include 了一个文件。这时候执行：
bash复制git reset --soft HEAD~1
HEAD~1 表示当前提交的上一个提交，也就是把分支指针往前移一格。--soft 模式下，你刚才 commit 的所有改动仍然留在暂存区，文件内容一点没丢。所以你可以直接补上漏掉的文件，再重新提交：
bash复制git add 漏掉的文件.java
git commit -m "feat: 新增用户模块"
这样最终提交记录只有一条，看起来就像一开始就没漏过。这种“撤销后立即重新提交”的操作，用 --soft 是最舒服的，因为不需要重新 add。
如果你记不清暂存区和工作区的区别，就用 --mixed。它是默认模式，执行 git reset HEAD~1 就等价于 git reset --mixed HEAD~1，效果是撤销提交，并把所有改动放回工作区，但暂存区会被清空。之后你想 add 哪些就 add 哪些，自由度最高。
2.2 --hard 是最后手段，别随手用
--hard 的破坏力最强，执行它会同时重置暂存区和工作区，相当于把分支指针之后的提交和所有未提交改动全部丢掉。除非你确实确认这些内容都不需要了，否则不要随手使用。
bash复制git reset --hard HEAD~1
上面这个命令会把最近一次提交以及提交里的所有改动全部清掉，工作区直接回到上一次提交的状态。注意，这里“丢掉的提交”也不是立刻从硬盘上消失，它在一段时间内还能通过 git reflog 找到，这个后面单独说。但从操作习惯上讲，--hard 仍然要谨慎，尤其是工作区还有未提交内容时。
我见过一种典型错误：有人想撤销提交但保留代码，结果执行了 git reset --hard HEAD~1，然后发现工作区里那些改了还没提交的内容也没了。这是因为 --hard 会连工作区一起重置，跟“保留改动”的需求完全相反。所以如果你只是想把提交撤掉、但改动要继续留着改，用 --soft 或 --mixed，绝对不要用 --hard。
2.3 reset 不是删除，reflog 还能找回来
刚开始用 Git 的人经常把 reset --hard 当成“彻底删除”，其实不是。reset 只是移动了分支指针，原本那个提交对象还留在本地对象库里，只是变成了“悬空提交”，没有任何分支引用它。Git 默认 90 天内不会清理这些悬空对象，所以你完全有机会找回来。
找回的方法是 git reflog。reflog 记录了 HEAD 指针过去移动过的每一步，包括你执行 reset 之前的指向。你可以查看它，找到事故前的提交哈希，然后执行 git reset --hard <哈希> 把整个状态切回去。这相当于给撤销操作加了一道保险。
提示：
git reflog是所有“撤销撤销”操作的救命通道。只要你的仓库本地还没被git gc清理，哪怕执行了reset --hard、revert、commit --amend这类操作，都有机会从 reflog 里找回原状。
3. git revert：撤销已推送提交的正确姿势，不篡改历史，只新增反做
git revert 的原理和 reset 完全不同。reset 是“把指针往回挪”，revert 是“在最新提交之后再生成一个反向提交”。比如你有一个提交把文件中 A 改成了 B，revert 就会生成一个新提交，把 B 改回 A。这样提交历史一直是往后走的，没有改写任何已存在的提交。
3.1 为什么公共历史不建议改写
假设你和同事各自 clone 了同一个仓库，你们的分支都指向同一个提交 X。现在你本地用 reset --hard 把历史改成了 X-1，然后强推到了远端。远端的分支变成 X-1，但同事本地的分支还停在 X。下次同事 git pull 时，Git 会发现远端历史和他本地历史不是前后继承关系，而是分叉了，于是要求他处理 merge 或 rebase。如果这个提交已经合入主干，影响面会更大。
revert 就不存在这个问题。它是在 X 之后再追加一个反向提交 X'，所有 clone 了这个仓库的人只需要正常 pull 就能拿到，不需要任何额外操作。所以在协作分支上，revert 是默认选择，这也符合前面说的“公共历史不可改写”的原则。
3.2 基本用法和参数选择
撤销最近一次提交：
bash复制git revert HEAD
撤销指定的某个提交：
bash复制git revert 9fceb02
其中 9fceb02 是提交哈希。执行后 Git 会打开编辑器，让你确认这次的提交信息，默认内容类似 Revert "feat: 新增用户模块"。如果你不想每次都被编辑器拦住，可以直接用 --no-edit：
bash复制git revert --no-edit HEAD
如果你是自动化脚本或 CI 场景，--no-edit 非常有用。它直接用默认提交信息完成 revert，不需要人工干预。日常手动操作时，保留编辑器让你看一眼默认信息也挺好，尤其是 revert 别人提交时，多看一眼提交说明能避免误撤销。
3.3 冲突、合并提交与批量撤销
revert 并不是永远顺滑。如果被 revert 的提交之后，同一段代码又被别的提交修改过，Git 可能无法自动生成反向修改，这时就进入冲突状态。Git 会提示你手动解决冲突，流程和普通 merge 冲突一样：打开冲突文件，保留想要的内容，然后执行：
bash复制git revert --continue
如果你发现这次 revert 是个错误，想放弃，则执行：
bash复制git revert --abort
这会让仓库回到 revert 之前的状态。我个人建议：revert 冲突时，先看冲突区域的代码再决定是继续还是放弃，不要机械地执行 git revert --abort。因为有些冲突恰恰说明当前代码依赖了被撤销提交里的逻辑，直接 abort 可能掩盖真问题。
另外还有一种特殊情况：如果被 revert 的提交本身是一个合并提交（merge commit），直接执行 git revert 会报错，提示需要 -m 参数：
bash复制git revert -m 1 <merge-commit-id>
-m 1 表示保留主线分支的历史，-m 2 表示保留被合并进来的那条分支的历史。具体选哪个，取决于你 revert 之后想要哪一侧的代码继续存在。我建议在 revert 合并提交前先用 git log --graph 看清楚分支结构，避免选错主线导致大量文件被错误回退。
如果要撤销连续多个提交，一条条执行 git revert 会很繁琐，可以一次暂存多个反向修改：
bash复制git revert --no-commit HEAD~3..HEAD
git commit -m "revert: 撤销最近三次提交"
HEAD~3..HEAD 表示最近 3 个提交的范围。--no-commit 会把所有反向修改叠加到暂存区和工作区，但不会立即生成提交，等你检查和整理后再统一 commit。这样做的好处是：如果某个反向提交让你不满意，可以先 git reset 放弃，再重新来过，不必生成一堆零碎的 revert 提交。
4. 已 push 的提交怎么撤销：force push 与 revert 两条路线如何取舍
日常问“怎么撤销 push”的人，通常真正想达成两个目标：要么是想让远端分支也回到某个旧状态，历史里看不到那次提交；要么是只想让远端代码内容回退，但历史保不保留无所谓。这两种诉求分别对应两条路线：reset + force push 和 revert + push。
4.1 两条路线的优劣与场景
| 路线 | 核心命令 | 优点 | 风险 | 适用场景 |
|---|---|---|---|---|
| A. 本地 reset 后强推 | git reset --hard <目标提交> + git push --force-with-lease |
远端历史干净，符合“彻底撤销”直觉 | 会改写公共提交，可能覆盖他人代码 | 分支只有自己用，刚 push 错，几分钟内发现 |
| B. 远端 revert 后推送 | git revert --no-edit HEAD + git push |
不产生分叉，协作者 pull 即同步 | 历史里多一条反向提交，不够“清爽” | 提交已共享、已合入主干、不允许强推 |
如果在团队协作里，我的默认优先级是：能 revert 就先 revert。哪怕提交是十分钟前刚 push 的，只要分支有其他协作者在拉取，revert 都是更保险的选择。历史里多一条反向提交，远好过让同事本地仓库出现历史分叉，然后他来问你为什么 pull 出一堆 merge commit。
4.2 为什么我坚持用 --force-with-lease
如果你确实需要强推，命令请用 --force-with-lease，不要用裸的 --force。
两者的区别在于：git push --force 是无条件把本地分支状态覆盖到远端，完全不检查远端这一段时间有没有新增提交。git push --force-with-lease 则会在推送前对比一下：你本地记录的远端引用和远端当前状态是否一致。如果一致，说明远端没有别人推过新内容，可以安全强推；如果不一致，Git 会拒绝推送并提示远端有更新，你需要先 git fetch 确认情况再决定是否继续。
这个差异在多人分支上非常关键。举个真实例子：你在本地 reset 到旧提交，准备强推覆盖远端，但这时候同事往这个分支推了一个新修复。如果你用 --force，修复提交会直接消失；用 --force-with-lease，你的推送会被拒绝，你就有机会先 git fetch，发现远端新增了什么，再考虑是否需要调整策略。所以不管分支有多少人用，我都建议形成肌肉记忆：强推一律写 --force-with-lease，不写裸 --force。
4.3 三个可直接套用的完整操作示例
场景一：提交并 push 后发现提交内容完全错误，想把本地和远端都恢复到上一个提交。
bash复制git reset --hard HEAD~1
git push --force-with-lease origin main
这里的 main 换成你实际的分支名。执行完，本地和远端都回到上一个提交状态。
场景二：本地已经重新整理好了提交历史，想覆盖远端，但希望强推前先检查远端是否被更新过。
bash复制git fetch origin
git push --force-with-lease origin 当前分支名
先 fetch 再强推是个好习惯。它可以先更新你本地的远端引用，让 --force-with-lease 的对比判断更准确。否则在多人高频推送的分支上，你本地的远端引用可能已经过期好久了。
场景三：提交已经 push 且不想改写历史，只想撤销最近一次提交并推送。
bash复制git revert --no-edit HEAD
git push origin 当前分支名
这条路线不需要强推，普通推送即可，协作者 pull 时不会遇到任何历史分叉问题。
注意：如果平台开启了保护分支（比如 GitLab 的 protected branch），force push 默认会被拒绝。这时候你有两个选择：一是申请临时解除保护，二是改用 revert 路线。绝大多数情况下，直接 revert 是更快的路。
5. 撤销后推送时常撞上的两个报错：src refspec 与 failed to push
撤销操作本身可能很顺利，但 push 阶段经常冒出两个高频报错。它们虽然不是专门属于撤销命令的报错，但我发现大量初学者是在“撤销后重新 push”这个环节第一次撞上它们。
5.1 error: src refspec master does not match any
这个报错常见于首次 push，或者本地分支名和远端分支名不一致的时候。它的核心意思是：Git 在本地找不到你指定的那个分支引用。
比如你执行了：
bash复制git push origin master
但本地仓库还没有 master 分支，或者你的默认分支叫 main，或者你还没提交过任何代码，就会看到类似：
text复制error: src refspec master does not match any
error: failed to push some refs to 'git@xxx:project.git'
出现这种情况，先用自己的眼睛确认分支名：
bash复制git branch --show-current
它会直接输出当前分支名。如果输出是 main，你就应该 push main。如果你确实想推到远端的 master，可以显式指定“本地分支:远端分支”的映射：
bash复制git push origin HEAD:master
HEAD 代表当前分支的最新提交，这种写法适合本地分支名和远端要求不一致的场景。还有一种可能是你刚执行过 git reset --hard 到一个没有任何提交的初始状态，分支上连一个提交都没有，此时 push 也会报这个错。解决办法是先重新提交一次再 push，或者确认目标远端分支是否还值得覆盖。
5.2 fatal: failed to push some refs
这个报错也很经典，通常表现为：
text复制! [rejected] main -> main (non-fast-forward)
error: failed to push some refs to 'git@xxx:project.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
翻译成人话就是：远端分支有你本地没有的提交，所以普通 push 被拒绝了。这个情况在“第一次 push 到远端已有初始提交的仓库”时最常出现，比如你在 Web 端建仓库时初始化了 README，本地又是刚 commit 的状态，两边历史没有共同祖先。它同样也出现在你 reset 之后准备 push 的场景里：你本地把历史回退了，但远端还保留着原来的提交，两边历史就分叉了。
解决方式看你的目的。如果只是想把自己的改动推到远端，不想覆盖远端内容，标准的做法是先拉取合并：
bash复制git pull --rebase origin main
--rebase 会把你的本地提交按顺序接到远端最新提交之后，避免生成一个多余的 merge commit。如果 rebase 过程中有冲突，就按冲突解决的流程处理，解决了再 git add、git rebase --continue，最后 push。
如果你的目的就是覆盖远端，让远端和本地完全一致，那这个报错其实是在提醒你：你正打算放弃远端的一些提交。这时候回到上一节的思路，确认分支是否只有自己在用，确认无误后再执行 git push --force-with-lease。不要什么都不检查，直接改 push 命令加 --force。
6. 顺带解决几个高频“卡住/失败”现场：编辑器、覆盖冲突与工具链
Git 的报错和“卡住”现场，很多跟撤销提交没有直接关系，但用户搜索时经常混在一起。我在答疑时经常遇到：执行 git revert 或 git merge 后，屏幕停在 please enter a commit message to explain why this merge is necessary，不知道怎么继续；或者 pull 时遇到 these untracked files would be overwritten by merge；还有在 VSCode、IDEA 里配置不好 Git 的情况。这些都值得单独讲一遍。
6.1 遇到 please enter a commit message 卡住，先别慌
这个提示出现在你执行 git merge、git revert 或 git cherry-pick 时，Git 自动打开了一个编辑器，想让你确认或填写提交信息。 如果你看到的是 Vim 界面，很多人会直接卡住，因为不知道怎么保存退出。
只需要三步：
- 按一下
Esc，确保退出插入模式。 - 输入
:wq。 - 按回车。
:wq 的意思是“保存并退出”。如果你想把默认提交信息改掉，就在打开编辑器后直接输入新内容，然后再 Esc、:wq。
如果你实在不想每次都被 Vim 拦住，可以把默认编辑器换成 VS Code：
bash复制git config --global core.editor "code --wait"
或者换成记事本：
bash复制git config --global core.editor "notepad"
设置之后，Git 不会再打开 Vim，而是在对应的编辑器里让你修改提交信息，保存关闭后命令就会继续执行。这样处理 revert 默认提交信息时会舒服很多。
6.2 these untracked files would be overwritten by merge
这个报错经常出现在执行 git pull 或者 git revert 拉取远程改动时。意思是：远端有一个文件路径，在你本地已经存在同名文件，但你这个同名文件还没被 Git 跟踪。Git 出于安全机制拒绝覆盖它。
我举个实际例子。你的项目里手动创建了一个 config/dev.yml 文件，但从未 git add 过，它属于“未跟踪文件”。同事在远端也新增了一个同名文件，你 git pull 时就会触发这个报错，提示这些 untracked files 会被 merge 覆盖。
处理方式分三步判断：
- 如果这个本地文件已经没用，确认可以舍弃，那就删除或备份后重新 pull。
- 如果这个文件的内容需要保留，先把它备份到其他地方，再执行 pull，然后把备份内容重新合并进去。
- 如果这个文件本来就该纳入版本管理，可以先 git add 再 commit，纳入跟踪后再 pull。
因为 git clean 这类命令会批量删除未跟踪文件，我建议尽量少用 git clean -fd。尤其在你不确定仓库里哪些文件属于“生成的临时文件”时，一条 git clean 下去可能把本地的配置、脚本全部删光，且没有后悔药。手动移动、备份，虽然笨但安全。
6.3 Git 命令找不到、IDE 里配不上 Git，该怎么查
“git 无法识别”是我在 Windows 用户里看到最多的问题。典型报错是：
text复制git : 无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称
这个问题的根源是 Git 安装后没有把 git.exe 所在的目录加入系统的 PATH 环境变量。解决方法有两条路：
- 重新运行 Git 安装包，在安装过程中勾选“Add to PATH”或“Add to Windows PATH”，装完重新打开终端。
- 手动配置环境变量，把
C:\Program Files\Git\cmd（根据安装路径调整）加到系统 PATH 里。
如果你是在 VSCode 或 JetBrains 系 IDE 里报类似错误，还要检查 IDE 里配置的 Git 可执行文件路径。以 IDEA 为例，路径在 Settings -> Version Control -> Git -> Path to Git executable，要指向 git.exe。VSCode 里则是 git.path 设置项。如果 IDE 显示“找不到 Git”，多半就是这里没配好。
如果用 TortoiseGit（小乌龟）这类图形客户端，它的安装和配置相对独立，但底层调用还是同一个 Git。遇到“小乌龟提交失败”类问题，仍然可以用命令行 Git 先排查原因。
另外，GitLab 用户偶尔会在 IDE 里遇到 login failed. check api token or gitlab version 之类的报错。这种问题通常和 Git 本身无关，核心是 IDE 的 GitLab 插件配置的访问令牌过期、API Token 没有权限或版本不兼容。处理顺序是：重新生成一个具有足够权限的 Personal Access Token，更新到 IDE 的 GitLab 设置里；确认连接的 GitLab 版本和 IDE 插件要求匹配；如果公司 GitLab 版本较老，有时需要降低 IDE 插件的 API 版本兼容配置。
7. 撤销后的救援通道：reflog 在90天内都能把提交捞回来
前面几节讲的是“怎么撤销”，这一节讲“撤销错了怎么救”。只要是 Git 仓库里的提交，大多数情况下都能救回来，哪怕你执行了 reset --hard。关键是你要知道去哪里找。
7.1 reflog 到底记了什么
git reflog 的全称是 reference log，中文一般叫引用日志。它会记录 HEAD 指针每次移动的记录，包括 checkout、commit、reset、merge、rebase、cherry-pick 等操作。换句话说，你每次切换分支、提交代码、回退版本，Git 都会往 reflog 里写一行记录。
执行：
bash复制git reflog
你会看到类似这样的输出：
text复制abc1234 (HEAD -> main) HEAD@{0}: commit: feat: 新增用户模块
9fceb02 HEAD@{1}: reset: moving to HEAD~1
7a1b2c3 HEAD@{2}: commit: fix: 修复登录跳转
这里每一条都对应 HEAD 过去的一次移动。HEAD@{1} 表示执行当前这个操作之前的状态，HEAD@{2} 再往前一步。如果你发现刚才 reset --hard 之后代码少了，就可以去 reflog 里找那个 moving to 之前的状态。
7.2 一个完整的找回案例
假设你之前的提交哈希是 7a1b2c3，某次提交后你觉得不满意，执行了：
bash复制git reset --hard 9fceb02
这时候当前分支指向了 9fceb02，原本的 7a1b2c3 提交里的改动在 git log 里看不到了。你第一反应可能是“完了，代码没了”。但其实 7a1b2c3 还躺在对象库里。恢复方式很简单：
bash复制git reflog
找到类似 HEAD@{1}: reset: moving to 9fceb02 的行，然后执行：
bash复制git reset --hard 7a1b2c3
执行完，当前分支又回到了之前的状态，那些“丢失”的提交全部回来。只要没有执行 git gc --prune=now 这类强制清理，默认 90 天内的 reflog 记录都有效。原则上，不到万不得已不要强制 gc，因为它会把你的救援通道一并清掉。
7.3 用 cherry-pick 精准恢复单个提交
有时候你不想把整个分支状态切回去，只想把丢失的某个提交里的改动重新应用出来，这时候 git cherry-pick 比 reset --hard 更精准。
流程还是先通过 git reflog 找到丢失提交的哈希，假设是 f3e4a5b，然后执行：
bash复制git cherry-pick f3e4a5b
Git 会把那个提交的补丁重新应用到当前分支上，并生成一个新提交。这种方法特别适合从误删的历史里捞单个功能，而不影响其他已经整理好的提交。比如你在 rebase 过程中把某个提交弄丢了，通过 reflog 找到它，再 cherry-pick 回来，比重新写一遍代码要高效得多。
我现在的标准动作是这样的：每次做危险操作前，先看一眼 git log --oneline -5，记住最近一两个提交的哈希；做 reset --hard 或 rebase 这种重写历史的操作前，临时记一下当前 HEAD 的位置；万一出了问题，直接 git reflog 找到这个位置，git reset --hard 回去。这套习惯帮我在多次误操作事故里毫发无损地救回代码，也推荐你尽早养成。