1. 为什么“回滚”这件事值得单独拿出来讲
刚接触 Git 那会儿，我对“回滚”的理解就一句话：把代码退回去。真到了团队协作里才发现，退回去这三个字背后藏着一堆坑——退错了分支、把别人的提交冲掉了、推送到远端之后又不敢动、revert 完合并到别的分支一堆冲突。这些问题我在实际项目里几乎全踩过一遍，所以这篇就把git reset、git revert以及 reset 的四种模式彻底讲清楚，顺带把那些文档里不会写的经验一起倒出来。
先把结论摆前面，方便你对号入座：
- 本地提交想“当没发生过”，用
git reset，配合不同模式决定工作区和暂存区怎么处理。 - 已经推到远端、别人可能已经拉过的提交，用
git revert，它生成一个反向提交，历史不动，最安全。 - reset 的四种模式（
--soft、--mixed、--hard、--keep）核心区别只有一个：动 HEAD、动暂存区、动工作区，这三样各动几个。
这篇适合谁看？写过几个 commit、用过git push，但一遇到“退回去”就心里发虚的人。也适合那些被git reset --hard坑过一次、想彻底搞明白原理的人。下面我按“思路拆解 → 细节解析 → 实操过程 → 问题排查”的顺序展开，每一步都尽量给到能直接抄的命令和背后的原因。
2. 回滚的整体思路与方案选型
2.1 先搞清楚 Git 的三个区域
要理解回滚，绕不开 Git 的三个区域，我用一个生活化的类比来讲：
- 工作区（Working Directory）：你电脑上能直接看到、能编辑的那些文件，相当于你书桌上摊开的草稿。
- 暂存区（Staging Area / Index）：你
git add之后放进去的地方，相当于你把草稿挑出来放进了“待提交”的文件夹。 - 版本库（Repository / HEAD）：你
git commit之后真正存进历史的东西，相当于已经归档进档案柜。
git reset的本质，就是移动 HEAD 指针，然后根据模式决定要不要顺带把暂存区和工作区也一起“回退”。而git revert完全不移动指针，它是新增一个提交来抵消之前的改动。理解了这个，后面四种模式就不用死记了。
2.2 reset 和 revert 到底怎么选
很多人纠结的点在于：到底用哪个？我的判断标准很简单，看两条：
- 这个提交推送到远端了吗？别人拉过吗？
- 我想要的是“历史干净”还是“历史可追溯”？
如果提交只在本地，没推过，那reset随便用，历史干净利落。如果已经推了，尤其是主干分支，那基本只能用revert，因为 reset 会改写历史，别人本地的历史和远端对不上，一拉就是一堆冲突甚至强制覆盖。
这里有个容易被忽略的点：reset改写的是提交历史本身，revert改写的是代码内容。前者是“时间倒流”，后者是“再写一笔把之前的账抹平”。团队协作里，时间倒流这件事只对你自己有效，对别人是灾难。
2.3 四种模式的选择逻辑
reset 的四种模式，我建议你按这个顺序去理解，而不是死背表格：
--soft：只动 HEAD，暂存区和工作区原封不动。适合“我想重新组织提交”，比如把三个 commit 合成一个。--mixed（默认）：动 HEAD 和暂存区，工作区不动。适合“我想重新 add 一遍再提交”。--hard：三个全动，工作区也回到目标状态。适合“这些改动我全不要了”。--keep：动 HEAD 和暂存区，但工作区里未提交的改动会尽量保留，如果和目标提交冲突就会报错中止。
--keep是四种里最少被提到、但实际很有用的一个，后面会专门讲它的适用场景。
3. 四种模式的核心细节与实操要点
3.1 --soft：只挪指针，其余不动
git reset --soft <目标commit>做的事情非常克制：只把 HEAD 指向目标提交，暂存区和工作区完全不变。这意味着你当前所有的改动，包括已经 commit 的，都会“退回”到暂存区里。
我常用的场景是合并多个提交。比如我本地连着提交了三次，写得比较碎，想合成一个干净的提交：
git log --oneline # a1b2c3d 第三次修改 # e4f5g6h 第二次修改 # i7j8k9l 第一次修改 git reset --soft HEAD~3 git status # 会看到三次修改的内容全在暂存区 git commit -m "合并为一个完整提交"这样三次提交就变成了一个，历史很干净。注意HEAD~3表示往回退三个提交，HEAD~1就是退一个，等价于HEAD^。
提示：
--soft之后如果直接git commit，会把暂存区里所有内容一起提交。如果你只想提交一部分，记得先git reset（默认 mixed）把暂存区清一下，再重新git add。
3.2 --mixed：默认模式，动暂存区
--mixed是git reset的默认行为，不写模式就是它。它动 HEAD 和暂存区，工作区不动。效果是：提交被撤销了，改动回到工作区，但没有 add。
这个模式我用得最多的是重新组织提交内容。比如我提交的时候手滑把两个不相关的改动混在一起了，想拆开：
git reset HEAD~1 # 等价于 git reset --mixed HEAD~1 git status # 改动都在工作区，未暂存 git add fileA.js git commit -m "只提交 A 的改动" git add fileB.js git commit -m "单独提交 B 的改动"--mixed和--soft的区别就一句话：soft 把改动留在暂存区，mixed 把改动丢回工作区。想直接再 commit 用 soft，想重新挑选用 mixed。
3.3 --hard：三个全动，最危险也最常用
git reset --hard <目标commit>会把 HEAD、暂存区、工作区全部回退到目标提交的状态。工作区里所有未提交的改动会直接消失，这是它最危险的地方。
它的典型场景是“这些改动我全不要了，回到某个干净状态”：
git reset --hard HEAD~1 # 回到上一个提交，当前提交的改动全丢 git reset --hard origin/main # 回到远端 main 的状态我踩过的最大的坑就是：本地改了一堆东西还没提交，手一抖git reset --hard，全没了。后来学乖了，执行 hard 之前先git stash或者git status确认一遍。
注意：
--hard丢掉的未提交改动，Git 基本救不回来（除非你之前 stash 过或者有 IDE 的本地历史）。执行前务必确认工作区没有你想留的东西。
3.4 --keep：保留未提交改动，冲突就中止
--keep是个比较冷门但很实用的模式。它动 HEAD 和暂存区，但会尽量保留工作区里未提交的改动。如果这些改动和目标提交之间有冲突，它会直接报错中止，不会强行覆盖。
场景是这样的：你在某个提交上改了点东西还没提交，突然想回到另一个提交看看，但又不想丢掉手头的改动：
git reset --keep HEAD~2 # 如果工作区改动和目标提交不冲突，就保留改动并回退 # 如果冲突，报错：error: Your local changes to the following files would be overwritten它比--hard安全，比--mixed更“聪明”——mixed 会把暂存区清空，keep 会尽量维持工作区现状。我一般在“临时切回去看个东西，但手头改动不能丢”的时候用它。
3.5 四种模式对比速查
| 模式 | HEAD | 暂存区 | 工作区 | 典型场景 |
|---|---|---|---|---|
--soft | 动 | 不动 | 不动 | 合并提交、重新组织 commit |
--mixed（默认） | 动 | 动 | 不动 | 撤销提交后重新 add |
--hard | 动 | 动 | 动 | 彻底丢弃改动 |
--keep | 动 | 动 | 尽量保留 | 保留手头改动的同时回退 |
这张表建议存下来，忘了就翻。核心记忆点：soft 只动头，mixed 动头加暂存，hard 全动，keep 动头加暂存但护着工作区。
4. revert 的完整实操与合并冲突处理
4.1 revert 的基本用法
git revert <commit>会生成一个新的提交，内容是目标提交的“反向操作”。原来加了什么，它就删什么；原来删了什么，它就加回来。历史不动，只是在末尾多了一笔。
git log --oneline # a1b2c3d 有问题的提交 # e4f5g6h 之前的提交 git revert a1b2c3d # 会弹出一个提交信息编辑框，默认是 "Revert ..." # 保存退出后生成一个新提交revert 之后，a1b2c3d这个提交还在历史里，只是它的效果被新提交抵消了。这就是它比 reset 安全的地方——历史可追溯，别人拉代码不会冲突。
4.2 revert 一个合并提交
revert 合并提交（merge commit）是个经典难点。合并提交有两个父提交，Git 不知道你要保留哪一边，所以必须用-m参数指定“主线”：
git revert -m 1 <merge-commit-hash>-m 1表示保留第一个父提交（通常是你合并进去的那个分支的主线），-m 2表示保留第二个父提交。选错了，revert 出来的结果会完全不对。
我踩过的坑：revert 了一个合并提交之后，如果之后想再把这个分支合并回来，Git 会认为“这个分支的改动已经被 revert 过了”，导致再次合并时那些改动不会重新出现。解决办法是要么 revert 那个 revert 提交，要么重新 cherry-pick 相关提交。这个坑很隐蔽，团队里踩过一次之后都会在文档里专门标注。
4.3 revert 后其他分支合并 master 冲突
热词里提到“master 分支 revert 后，其他分支合并 master 冲突”，这个场景太真实了。原因在于：master 上 revert 了某个提交，其他分支还保留着那个提交的原始改动，合并时 Git 发现两边对同一块代码的处理不一致，就冲突了。
处理思路有这么几条：
- 确认冲突文件：
git status看哪些文件冲突，git diff看具体差异。 - 判断保留哪边：如果那个改动确实不要了，就保留 master 的版本（即 revert 后的状态）；如果还要，就保留分支的版本。
- 手动解决后 add + commit：
git add <file>然后git commit完成合并。
更稳妥的做法是：revert 之前先通知团队，让大家知道这个提交被撤销了，避免各自分支还基于旧逻辑开发。协作里很多冲突不是技术问题，是沟通问题。
4.4 revert 和 reset 的协作策略
我的实际经验是：本地用 reset，远端用 revert。具体来说：
- 本地还没推的提交，随便 reset，怎么方便怎么来。
- 已经推到共享分支的提交，一律 revert，哪怕它看起来很丑。
- 如果非要 reset 远端分支（比如刚推上去发现错了，且确认没人拉过），可以用
git push --force-with-lease，但一定要确认没人拉过，否则就是给别人挖坑。
--force-with-lease比--force安全一点，它会在推送前检查远端有没有别人的新提交，有就拒绝。但即便如此，共享分支上我还是不建议用。
5. 常见问题与排查技巧实录
5.1 reset 之后发现退错了怎么办
这是最高频的问题。分两种情况：
情况一：还没做其他操作。用git reflog找回。reflog 记录了 HEAD 的每一次移动，包括 reset：
git reflog # a1b2c3d HEAD@{0}: reset: moving to HEAD~1 # e4f5g6h HEAD@{1}: commit: 之前的提交 git reset --hard e4f5g6h # 回到 reset 之前的状态reflog 是 Git 的“后悔药”，默认保留 90 天。只要提交过，基本都能找回来。
情况二：reset --hard 丢了未提交的改动。这种基本救不回来，因为那些改动从来没进过 Git 的对象库。唯一的希望是 IDE 的本地历史（比如 IntelliJ 的 Local History、VS Code 的 Timeline），或者你之前 stash 过。所以再次强调：hard 之前先 stash。
5.2 revert 之后想撤销 revert
直接 revert 那个 revert 提交就行：
git revert <revert-commit-hash>这样原来的改动就回来了。这也是处理“revert 合并提交后无法再次合并”问题的标准做法之一。
5.3 常见报错速查
| 报错信息 | 原因 | 解决 |
|---|---|---|
fatal: not a git repository | 当前目录不是 Git 仓库 | cd到仓库目录，或git init |
error: Your local changes would be overwritten | reset --keep 时工作区有冲突改动 | 先 stash 或 commit，再 reset |
fatal: bad revision 'HEAD~3' | 提交数量不够 | 用git log确认提交数，减少回退步数 |
CONFLICT (content): Merge conflict in xxx | revert 或合并时内容冲突 | 手动解决冲突后 add + commit |
curl: (35) tcp connection reset by peer | 网络层连接被重置，和 Git 回滚无关 | 检查网络，重试操作 |
最后一行那个报错经常被误认为是 Git 问题，其实它是网络层的，和 reset/revert 没关系，别被带偏了。
5.4 几个实操心得
- reset 前先
git status：确认工作区有没有不想丢的东西，这个习惯能救你无数次。 - revert 合并提交务必记
-m：忘了加会直接报错，选错父提交结果全错。 - 共享分支永远 revert：这条我当成铁律，reset 只在自己分支上用。
- reflog 是你的朋友：任何“退错了”的恐慌，先
git reflog看一眼，大概率能救。 - force push 前先喊一声：哪怕用了
--force-with-lease，也告诉团队一声，避免有人正在基于旧提交工作。
6. 一套完整的回滚操作流程
把上面的东西串起来，给一套我实际用的流程。假设场景是：本地提交了三个 commit，想合并成一个，然后发现其中一个改动有问题，需要撤销。
第一步，合并提交：
git log --oneline # c3 第三次 # c2 第二次 # c1 第一次 git reset --soft HEAD~3 git commit -m "合并三次提交"第二步，发现合并后的提交有问题，但已经推到远端了，用 revert：
git log --oneline # d4 合并三次提交 git revert d4 # 生成反向提交，历史保留 git push第三步，如果 revert 过程中冲突：
git status # 看冲突文件 # 手动编辑解决冲突 git add <冲突文件> git revert --continue # 继续完成 revert第四步，如果中途想放弃 revert：
git revert --abort这套流程覆盖了从本地整理到远端撤销的完整链路。核心原则再强调一遍：本地 reset，远端 revert，动手前先 status，出事先看 reflog。
我个人在实际操作中的体会是，Git 回滚这件事，命令本身不难，难的是判断“当前这个提交到底该用哪种方式退”。把三个区域和四种模式的关系理清楚，再记住“共享分支不 reset”这条底线，基本就不会出大问题。最后再分享一个小技巧：把git reflog设个别名，比如git config --global alias.rl reflog，出事的时候敲git rl就能快速定位，比翻文档快得多。
