git revert 是撤销已推送提交的唯一安全方式，它新增反向提交抵消变更、保留原始历史；需注意合并提交加 -m 1、多 commit 按时间倒序、冲突时用 --continue 或 --abort。
已推送的提交不能用 git reset --hard 直接回退——除非你确认没人基于它开发过，否则会破坏协作。真要撤回，git revert 是唯一安全的选择。
git revert 撤销已 push 的单个提交
它不删历史，而是生成一个新提交，内容刚好抵消目标提交的所有变更。别人 pull 时不会重复引入问题，Git 也能识别“这个改动已被撤销”。
常见错误现象：执行 git revert abc1234 后卡在编辑器里，以为卡死；其实只是 Git 在等你确认提交信息，默认是 Revert "xxx"，直接保存退出就行。
- 撤销单个提交：
git revert abc1234 - 撤销连续多个（含 abc1234 到 def5678）：
git revert abc1234^..def5678（注意^表示“不包含起点”） - 遇到冲突？改完文件 →
git add .→git revert --continue - 中途想放弃？
git revert --abort立刻清理现场
git reset --hard 为什么不能乱用
它直接把 HEAD、暂存区、工作区全拽回指定版本，后续提交在本地“消失”。一旦 push 过，再用 --force 推送，等于要求所有人同步你的新历史——只要有人已经基于被删提交做了开发，他们的 git pull 就会出错或丢失工作。
容易被忽略的细节：git reset --hard 不仅丢提交，还会清掉你 git add 过但没 commit 的文件状态，且无法通过常规方式恢复（除非你记得查 git reflog 并用 git reset --hard HEAD@{1} 找回来）。
- 只适合未推送、或你百分百确认团队全员同步操作的场景
- 误用后远程拒绝强制推送？可能是分支被保护（如 GitLab 的
main分支），需先去网页端取消保护 - 想保留修改只撤回 commit？用
git reset --soft HEAD~1，别上--hard
怎么判断该用 revert 还是 reset
核心就一条：那个出问题的 commit，有没有被别人 fetch 或 pull 过？
- 没推过，或只在自己本地分支：用
git reset --hard最快 - 已
push到远程，且别人可能基于它开发：必须用git revert - 推了但刚发生、还没人拉？可考虑
git reset --hard+git push --force-with-lease（比--force安全，会检查远程是否有新提交）
真正容易被忽略的是：revert 不是万能的。如果目标提交后面有大量冲突性修改（比如同一行被反复改过），revert 可能失败，需要手动解决；而 reset --hard 看似干脆，但它删掉的不只是提交——还有你刚 add 进去却忘了 commit 的配置文件、临时调试代码，这些都会无声无息地消失。
