必须用 git revert 的情况是：已 push 且他人已 pull 或 CI/CD 已构建的提交，即“已发布历史”，此时 revert 生成反向新提交以安全撤销；reset 仅限本地或无人依赖时使用。
别用 git reset --hard 去动别人已经拉过的分支——它直接删历史，远程强制推送会炸掉队友的本地分支。 团队协作中，该用 git revert 的地方硬上 reset，轻则引发 merge 冲突雪球，重则丢掉他人基于你提交做的开发。
什么时候必须用 git revert
你 push 过的提交，别人 git pull 过、或者 CI/CD 已构建过，就属于“已发布历史”，不能再改。这时 git revert 是唯一安全选择。
- 执行
git revert <commit-id>后，Git 生成一个新提交，内容是“把目标提交的所有变更再反向应用一遍” - 如果撤销连续多个提交（比如想撤掉
a1b2c3到d4e5f6），用git revert a1b2c3^..d4e5f6（注意^表示“不包含起点”） - 遇到冲突？和
git merge一样：手动改完文件 →git add .→git revert --continue - 中途想放弃？
git revert --abort立刻回退到 revert 前状态，不残留任何临时信息
什么时候可以考虑 git reset
git reset 只适合你一个人在本地玩、或你确定远程分支没人依赖、且你有权限强制同步所有人。
-
git reset --soft <commit-id>：只移动 HEAD，暂存区和工作区全留着——适合改错提交信息，或想把几次提交压成一次 -
git reset --mixed <commit-id>（默认）：HEAD 和暂存区重置，工作区文件不动——适合重新add部分文件再提交 -
git reset --hard <commit-id>：三者全清空，文件内容直接倒退回目标版本——这是唯一真·丢代码的操作，git fsck --lost-found可能救回，但别指望
git reset --hard 推送到远程前必须确认三件事
强制推送不是按个回车的事，它直接影响所有协作者的本地状态。
- 有没有人基于你要砍掉的那些提交做了新开发？查 GitHub/GitLab 的 “Network” 图或 “Activity” 日志，确认最近一次健康提交的
commit-id - 远程分支是否被其他人保护（如 protected branch）？
git push -f会被拒绝，得先找管理员解保护 - 你本地
git log看到的“旧版”是否真就是你想恢复的版本？别只看消息，用git show <commit-id>对比关键文件内容
误操作后怎么抢救
最危险的不是用错命令，而是用错之后还继续乱操作。
-
git reset --hard后发现错了？立刻执行git reflog，找到 reset 前的HEAD@{0}或HEAD@{1}，再git reset --hard HEAD@{1}拉回来 -
git revert --continue卡住？别关终端，先git status看哪些文件还在 unmerged 状态，改完再继续 - 已经
push -f把远程搞乱？别急着再推，先让所有人git fetch origin，再各自用git reset --hard origin/main强制对齐——前提是你们都同意丢弃本地未 push 的提交
真正难的不是记住命令参数，而是每次敲下 git reset --hard 或 git push -f 前，花 10 秒确认：这个提交，到底有没有人正在用？
