git reset 和 git revert 有什么区别？已经推送的提交应该怎样撤销？

知识点详解：两种撤销，改变的是不同对象

reset 先改变分支所指的位置

咱们假设历史是 A → B → C，当前分支指向 C。如果把分支 reset 到 B，分支就不再通过这条路径包含 C。

不过，文件怎样处理还要看模式：

模式	分支位置	暂存区	工作区
soft	移到目标	保留	保留
mixed	移到目标	重置	保留
hard	移到目标	重置	重置，存在数据丢失风险

Git reset 官方文档给出了这些模式的行为。默认 mixed，不代表一定没有风险；目标选择错误也可能打乱已有工作。

这里解释命令语义，不在你的仓库中执行撤销。真实操作前需要检查 git status，并妥善保留尚未提交的工作。

revert 不抹去 C，而是追加一个修正

同样是 A → B → C，对 C 执行 revert，正常情况下得到 A → B → C → R。R 尝试反向修改 C 带来的变化。

所以，原提交仍然可以追溯。其他人更新分支时，获得的是一个新提交，不需要把自己的历史强行替换成另一条。

Git revert 官方文档说明了反向修改与冲突处理。它不是把整个项目快照强制恢复为 C 之前的样子；C 后面的相关修改可能影响反向应用，甚至引发冲突。

已推送，意味着还要考虑其他人的历史

如果远端已经包含 C，把本地分支 reset 到 B以后，普通推送通常不能直接用旧历史替换新历史。强制推送可能让其他人的分支与远端不一致。

因此，共享历史上的修正通常使用 revert。团队确实约定可以重写某些分支时，也要明确协作范围和恢复方案，不能仅凭“我推送的提交”就认为只有自己受影响。

反过来，本地尚未共享的提交需要调整顺序、重新组织，reset 等历史编辑工具就可能适合。判断依据是协作状态，不是命令哪个更熟悉。

撤销以后，仍要确认代码语义

假设 C 引入了一个字段，后来的 D 已经依赖它。反向删除字段可能让 D 无法工作，即使 Git 没有文本冲突。

所以，需要测试实际功能。文本合并成功，只能说明修改可以应用，不能证明业务行为正确。

合并提交还有多个父提交，revert 时需要明确相对哪个主线计算反向变化。后续再合并也会受到历史关系影响，不能把普通提交的例子直接套过去。

如果操作错误，reflog 有时能够帮助找到本地曾经的引用位置，但它不是可靠的长期备份，也不能保证恢复所有未提交文件。先保护数据，比事后期待找回更重要。

面试官继续追问

已推送但没人用，可以 reset 吗？

需要团队确认分支允许重写，并核实没有其他依赖。仅凭没有人回复，不等于确定无人使用。共享主分支尤其应优先追加修正。

revert 之后能再恢复原修改吗？

可以考虑反向撤销 revert 或重新应用所需修改，但仍要检查现在的代码与依赖。不应把命令嵌套理解成无条件回到某个状态。

soft 和 mixed 最常见的区别是什么？

soft 保留暂存区，mixed 会重置暂存区但保留工作区。两者都可能让修改留在本地，只是暂存状态不同。

面试速记卡

• reset：移动分支，模式决定暂存区与工作区处理。
• revert：追加反向提交，原历史保留。
• 共享历史：通常用追加修正，谨慎重写。
• hard 风险：可能丢弃未提交工作，不是普通撤销按钮。
• 验证重点：命令成功还要检查后续依赖与实际功能。