git revert 是安全回滚已推送提交的首选操作，通过创建反向新提交抵消变更，不修改历史，适用于公共分支；而 git reset --hard + force push 仅限私有分支且风险极高。
git revert 是安全回滚的首选操作
已经 push 到远程的提交，不能直接 git reset --hard 后强推（除非你明确知道所有协作者都已同步、且团队允许强制更新）。更稳妥的做法是用 git revert 生成一个“反向提交”，把原提交的变更抵消掉，既保留历史可追溯性，又不影响他人本地分支。
常见错误现象：有人在 git reset --hard 后执行 git push --force，导致其他人在 pull 时遇到冲突或丢失提交；尤其在共享分支（如 main 或 develop）上极不推荐。
- 对单个提交回滚：
git revert <commit-hash>（例如git revert a1b2c3d），会打开编辑器让你确认提交信息 - 对连续多个提交（按时间倒序）：
git revert <oldest-commit>^..<newest-commit>，注意^表示“不包含起点” - 如果中间某次 revert 引发冲突，需手动解决后
git add . && git revert --continue
强制回滚（git reset + force push）只适用于私有分支或紧急修复
如果你确定该分支只有你一人使用（比如功能分支 feat/login-ui），或者团队已约定允许强推（如 CI/CD 流水线失败后清理测试分支），才考虑重置 + 强推。否则风险极高。
性能与兼容性影响：强推会改写远程分支的 commit history，所有依赖该分支的 PR、CI 构建记录、甚至 GitHub/GitLab 的提交关联都可能失效。
- 先本地重置：
git reset --hard <target-commit>（例如回到上上个提交：git reset --hard HEAD~2） - 再强推到远程：
git push --force-with-lease origin <branch-name>（--force-with-lease比--force安全，能防止覆盖他人新 push 的内容） - 绝对不要用
git push --force直接强推，尤其对main、master这类受保护分支
远程分支被误删或需要彻底恢复旧状态？查 reflog 不顶用，得靠 remote 的引用
本地 git reflog 只记录你本机的操作历史，无法找回已被远程删除或强推覆盖的提交。真正可靠的方式是检查远程仓库本身是否还保留着那些 commit —— 大多数托管平台（GitHub、GitLab、Gitee）默认不会立即 GC 掉“不可达”对象，通常保留数周。
- 先确认目标 commit 是否还在远程：
git ls-remote origin | grep <partial-hash> - 如果存在，可直接基于它创建新分支：
git checkout -b recover-branch <commit-hash>，再 push 上去 - 若远程已彻底清理，且本地也没有备份，唯一办法是找协作者的本地仓库
git log或从 CI 构建产物中提取代码快照
GitHub / GitLab 上的保护分支怎么处理？
如果你面对的是启用了 branch protection 的远程分支（比如要求 PR、状态检查、禁止 force push），那么 git revert 是唯一合法路径 —— 因为它只是普通提交，走正常 CI/CD 流程即可合并。
容易踩的坑：试图绕过保护机制，比如临时关闭保护 → 强推 → 再开启，这会中断审计链，很多公司安全策略明令禁止。
- 确保你的 revert 提交通过所有 CI 检查（包括 lint、test）
- 如果 revert 后还需保留部分变更，不要二次修改 revert 提交，而是基于 revert 后的状态再提交新 patch
- 某些企业 Git 配置禁用了
push权限，此时必须走 Web 界面发起 Pull/Merge Request
最常被忽略的一点：revert 提交本身也是提交，它会出现在 git log 里，也会被后续 git bisect 或自动化工具识别。如果你在排查问题时看到一个“看似修复了 bug”的 revert 提交，别急着跳过 —— 它很可能正是问题引入点的反向标记。
