该用 git reset 还是 git revert，核心看两点：提交是否已推送到远程共享分支，以及是否允许改写历史；已推送且他人可能基于其开发，必须用 git revert；仅本地未推送，可用 git reset --hard 安全回退。
已推送的分支不能直接 git reset --hard，否则协作者拉代码会出错；没推送的才可放心硬重置。选对命令的关键，是先确认“代码推没推送”和“要不要留历史记录”。
怎么判断该用 git reset 还是 git revert
核心就看两点：远程分支有没有别人基于它继续开发、你是否允许改提交历史。
- 本地刚提交、还没
git push：优先用git reset --hard <commit-hash>，快准狠 - 已经
git push到origin/main或类似共享分支：必须用git revert <commit-hash>，否则别人git pull时会看到“missing commit”或合并冲突 - 不确定有没有人拉过？查
git log origin/main对比本地git log，只要远程有你没看到的提交，就别 reset
git reset --hard 丢代码了还能找回来吗
能，但得趁早——Git 的 reflog 默认保留 30 天操作记录，刚执行完 git reset --hard HEAD~1 就发现错了，99% 能救回来。
- 运行
git reflog，找到 reset 前那行，比如abc1234 HEAD@{1}: commit: fix user login - 执行
git reset --hard abc1234或git reset --hard HEAD@{1} - 如果
reflog被清空（比如手动执行过git gc），且没建备份分支（如git branch backup-before-reset），那就真没了
撤销上一次提交但保留修改，为什么别用 --hard
因为 git reset --hard HEAD~1 不仅删提交，还清空工作区——你刚写的 200 行代码全没了。其实多数时候你只是想“撤掉这次提交，代码留着再改改”。
- 只撤提交、保留暂存区（适合改提交信息）：
git reset --soft HEAD~1 - 撤提交 + 清暂存区、但保留工作区文件（适合重选文件再提交）：
git reset HEAD~1（等价于--mixed） -
--hard是唯一会删工作区内容的选项，除非你明确要丢弃全部本地改动，否则它不是“撤销提交”的默认解
强制推送 git push --force 的安全边界
强制推送不是不能用，而是必须满足两个前提：分支没人协作、你清楚后果。
- 私有功能分支（比如
feature/login-v2）：可以git push --force-with-lease（比--force更安全，避免覆盖他人新提交） - 主干分支（
main/develop）：禁止直接--force；已误推，立刻通知所有人，并让他们执行git fetch && git reset --hard origin/main -
--force-with-lease比--force多一层检查：如果远程分支在你 fetch 后被别人更新过，它会拒绝强推，避免静默覆盖
真正容易被忽略的点是：回退操作本身不解决业务逻辑错误。比如你用 git revert 撤销了一个引入内存泄漏的提交，但那个泄漏可能已在生产环境持续数小时——命令能还原代码，不能还原状态。上线前务必结合日志、监控确认副作用是否清除。
