git push --force-with-lease 比 -f 安全但非万能，它仅在本地缓存的远程分支哈希与服务器当前哈希一致时才允许推送；若长期未执行 git fetch origin 导致缓存过期，该命令将退化为不安全的 -f，失去保护作用。
git push --force-with-lease 比 -f 安全，但不是万能保险
它只在「你本地缓存的远程分支哈希」和「当前远程真实哈希」一致时才允许推送。一旦你很久没 git fetch origin，本地缓存就过期，--force-with-lease 就会退化成 -f，完全失去保护作用。
常见错误现象：! [rejected] main -> main (stale info) 报错后，有人直接切回 -f 了事——这等于主动绕过安全机制。
- 每次准备强推前，必须先执行
git fetch origin（不是pull，避免自动 merge 干扰） - 指定分支名是硬性要求：
git push --force-with-lease origin main，不能省略main - 如果远程已启用 protected branch（GitHub/GitLab 默认对
main开启），命令会直接被平台拒绝，报错类似remote: GitLab: You are not allowed to force push branches，此时不是命令写错了，而是权限或策略问题
哪些分支真能用强制推送？
能用，不等于该用。真正合理的场景非常有限，且都满足一个前提：没人基于该分支做后续开发。
- 刚做完
git rebase -i或git filter-branch的个人特性分支，且确认无人拉取过 - 误推了密钥、大文件或敏感信息，且已确认团队中无人基于该提交继续工作
- CI/CD 自动生成的临时分支（如
ci-build-123），纯脚本控制，无协作风险 - 纯个人项目，远程仓库只有你自己访问，且本地已用
git reflog备份好关键提交
main、develop、release/* 这类共享分支，只要开了 protected branch，--force-with-lease 和 -f 都会被拦截——这不是 Git 的限制，是平台级防护。
强制推送前必须做的 5 件事
跳过任何一项，都可能让一次“清理历史”的操作变成团队事故。
- 运行
git fetch origin同步远程引用，确保本地知道别人有没有新提交 - 用
git log origin/main..main（把main换成你的目标分支）确认本地比远程多出哪些提交 - 用
git log main..origin/main反向检查：远程有没有你本地没有的提交？如果有，说明别人已经往这个分支 push 过 - 在团队沟通工具里明确告知：“接下来 5 分钟将对
feature/login强制推送，请勿在此期间基于该分支开发” - 本地执行
git branch backup-before-force main创建备份分支，防止手抖删错
推完发现错了，怎么紧急恢复？
Git 不会立刻删除旧对象，只要没触发 git gc，通常有 30 天窗口期可找回。
关键前提是：你或同事其中一人还保留着被覆盖前的提交哈希。
- 查本地
git reflog show main，找被覆盖前的 HEAD@{n} 记录 - 如果本地没记录，去其他协作者机器上运行
git ls-remote origin，看是否还能看到旧提交哈希 - 找到哈希后，新建分支指向它：
git checkout -b recover-from-old <old-commit-hash></old-commit-hash> - 再用
git push --force-with-lease origin recover-from-old:main把旧状态“救”回来（注意冒号语法）
最常被忽略的一点：恢复操作本身仍是强制推送，同样要走 fetch + lease 流程，而不是直接 -f ——否则可能再次覆盖掉刚拉回来的内容。
