接到这类回滚需求时，我先不看命令，而是先确认当前分支的状态和提交历史。选择 reset 还是 revert，决定因素不是哪条命令好记，而是这个分支是否已经推送、有没有人基于它继续开发。

回滚到指定提交时，reset和revert命令的用法差异明显。使用reset，先确保工作区干净，然后执行git reset --hard ，这会同时重置暂存区和工作区。若只想移动指针而保留改动，可用git reset --soft（保留暂存区）或git reset --mixed（保留工作区，默认）。使用revert，直接运行git revert ，Git会创建一个反向提交；如果目标提交不是最近提交，可能产生冲突，需要手动合并。注意revert只撤销该提交本身的变更，不影响后续提交。

先确认现象和分支状态

我会先执行 git status 确认工作区是否干净，再用 git branch -vv 看分支的跟踪关系，最后用 git log --oneline --all --decorate 看提交图。这个顺序能让我在改动前知道三个关键信息：目标提交ID、当前分支位置、以及远端分支是否比本地领先。

判断依据很简单：

git reset和git revert都用于撤销变更，但实现方式不同。reset直接移动分支指针，将当前分支指向目标提交，之后的提交从历史中消失；而revert则是生成一个新的提交，反向应用目标提交的变更，原历史保持不变。因此，如果分支尚未推送且没有他人基于它工作，reset干净利落；如果分支已经与远程共享，revert更安全，不会改写历史。这是选择时的基本判断依据。

这里补一句：即使分支没推送，也不意味着 reset 一定安全。如果本地有未提交改动，reset --hard 会一并丢弃，所以需要先看 status 输出。

容易误判的几个点

最常见的误判是把 git reset 和 git checkout 混用。checkout 是切换分支或恢复文件，不会移动分支指针；reset 才是针对提交历史的操作。另一个误判是以为 revert 会删除历史提交，实际上 revert 只是生成一个反向提交，原提交还留在历史里。

还有一个容易忽略的点：reset 之后的提交并没有被真正删除，而是变成了不可达对象。只要知道提交 ID，用 reflog 或 fsck 还能找回来。如果不清楚机制，直接再 reset 到另一个提交，反而可能把原来想恢复的提交覆盖掉。

我习惯在动手前把目标提交 ID 写完整，不用缩写，避免在命令里输入错误。

建议的处理顺序

确认完现象，我会按下面的流程操作。这个流程不是固定答案，而是让每一步都有可检查的中间状态。

第一步，如果有未提交改动，先 git stash 备份。第二步，根据分支状态选命令。具体区别如下：

回滚到指定提交时，reset和revert命令的用法差异明显。使用reset，先确保工作区干净，然后执行git reset --hard <commit>，这会同时重置暂存区和工作区。若只想移动指针而保留改动，可用git reset --soft（保留暂存区）或git reset --mixed（保留工作区，默认）。使用revert，直接运行git revert <commit>，Git会创建一个反向提交；如果目标提交不是最近提交，可能产生冲突，需要手动合并。注意revert只撤销该提交本身的变更，不影响后续提交。

也就是说，如果只需撤销最近一次提交且本地分支没推送，reset --hard 是直线操作。如果是在共享分支上，revert 更稳，但要接受冲突和额外提交。

命令执行后，reset --hard 之后工作区会变干净，分支头指向目标提交。revert 之后如果出现冲突，编辑冲突文件，然后 git add 和 git commit，不要对 revert 生成的临时提交再 reset。

风险边界和回滚防护

很多事故发生在共享分支上，所以这里单独展开风险边界。

风险边界要分清。reset --hard是破坏性最强的操作，会丢弃工作区和暂存区所有未提交修改，且改写分支历史；若分支已推送，必须强制推送才能同步，这会殃及协作者。revert不会改写历史，但会累积提交记录，且当后来某次提交与目标提交修改同一行时，revert会冲突。reset --soft和--mixed相对温和，分别保留暂存区和工作区，适合想撤销提交但保留代码的场景。务必在操作前用git stash备份未提交改动。

如果分支已推送，而你确定要用 reset 修正远端历史，不建议直接 git push --force。更保守的做法是先用 git push --force-with-lease。--force-with-lease 的检查机制是：只在远端分支没有被其他人更新时才会推送成功，这样能减少覆盖他人提交的概率。但即便如此，也要提前和协作者沟通。

revert 的冲突通常发生在目标提交和后来提交修改了同一行。解决冲突后，反向提交只针对目标提交的内容，后续提交仍保留原样。所以 revert 之后最好用测试或人工核查一下结果。

回滚后的验证方法

回滚后，我会依次看三个地方。第一个是 git status：reset --hard 之后应该显示 clean；revert 解决冲突后也应该 clean。第二个是 git log --oneline -3：reset 后分支头指向目标提交，revert 后会看到一条新提交，说明是反向提交。第三个是 git reflog：即使误操作，reflog 也会记录分支指针的每次移动，找到之前的提交ID就可以恢复。

举个例子，假设误 reset 到一个错误提交，reflog 会显示原本分支头的位置。这时用 git reset --hard <reflog中的ID> 就能回到原状。这个命令同样适用于误删提交的情况。

最后建议把这次操作记录到项目文档或笔记里，方便下次直接参考。Git 操作方式很多，关键是每次操作前都确认分支状态和远程同步情况。