强制推送不是一条需要每天使用的命令。在多人协作的 Git 仓库里，普通 push 被拒几乎每天都会出现，但只有少数情况需要动用 --force。第一步先判断是不是真的分叉了。

当远程分支的提交历史与本地分支出现分叉，且你确信本地版本才是正确基线时，需要强制推送。判断条件很简单：执行 git status 后看到 “Your branch and 'origin/xxx' have diverged”，或者远程分支领先但本地存在未推送的修复提交。此时普通 git push 会被拒绝，提示 “non-fast-forward”。只有出现这类信息，才考虑使用 --force 选项，否则直接推送即可。

普通 push 被拒，先看分叉情况

当远程分支上有你本地没有的提交，而本地也有远程没有的提交，Git 会拒绝普通推送。常见提示是 “Your branch and 'origin/xxx' have diverged”，或者直接显示 rejected (non-fast-forward)。此时先不要急着加 --force，先看当前分支和远程分支的差异。如果只是远程领先，本地没有独有提交，改用 git pull --rebase 后重新推送即可；只有当本地确实包含需要保留的修复或新代码，远程分支近期没有被强制改写时，才走下一步。

推送命令：--force 与 --force-with-lease 的差别

当确认需要覆盖，命令本身很简单。这里需要区分两个选项：

git push --force-with-lease origin 分支名

两者都会让远程分支强制指向本地分支，差别在于推送前是否检查远程状态。具体取舍看下面这段：

强制推送的标准命令是 git push --force origin 分支名。但更推荐使用 --force-with-lease，它会在推送前检查远程分支是否已发生变化：如果在你最后一次 fetch 之后远程被他人更新过，推送会被拒绝，从而避免覆盖别人的新提交。命令为 git push --force-with-lease origin 分支名。若确认要覆盖，也可缩写为 git push -f，但 --force-with-lease 多提供一层安全保障。

实际操作时，建议先执行 git fetch origin，再执行 --force-with-lease。这样让本地缓存的最新远程状态尽量贴近真实，减少因远程更新而误拒的情况。如果命令被拒绝，说明在你的缓存之后有人推过，先拉取并判断是否真的需要覆盖。

推送前核对：本地分支到底在指向什么

在按下回车之前，先做一次提交差异核对。执行 git branch -vv 可以看到当前本地分支关联的远程分支，以及领先或落后多少个提交。再用 git log --oneline --graph --all 对比本地分支和远程分支的提交历史：本地分支是否包含所有需要的代码，远程分支是否有一些本地没有的独有提交。如果远程分支上存在已经被关闭的合并请求留下的提交，强制覆盖后这些内容会消失，不能从 Git 历史里找回。有需要就先导出备份。

覆盖后的风险：谁的本地提交会失效

强制推送的影响范围不限于当前分支，所有已经拉取过旧远程分支的人都会受到影响。

强制推送会直接改写远程分支的历史，导致其他协作者基于旧历史创建的本地分支失效。若团队成员已经拉取并基于旧远程分支开发，覆盖后他们下次 pull 时会遇到大量冲突，甚至可能把自己的提交推回来。该操作只适合个人维护的分支、尚未合并的临时分支，或团队明确约定可以重写的共享分支。对于已合并到主干的长期分支，应改用 revert 或补丁，而不是强制推送。

如果你不能确定团队其他成员是否已基于旧分支做了提交，先停下来问一圈。需要重写共享分支时，提前在聊天工具里通知，给出操作时间窗口，比事后解释原因要容易得多。

如果已经覆盖：怎么找回旧提交

误覆盖之后，先别急着把所有分支都重推。找到旧提交哈希是恢复的第一关键。

覆盖远程分支后并非完全无法挽回，前提是你知道原来的远程提交哈希。如果其他协作者在该分支被覆盖前通过 git fetch 拉取过，那么原提交仍保存在对方的本地仓库中。你需要从对方那里拿到旧的 SHA，然后执行 git push --force origin 旧SHA:分支名 就能还原。如果你自己本地也没有旧引用，可以检查 reflog：git reflog show origin/分支名，但该记录通常只在最近一段时间内存在，时间越久越难恢复。

reflog 是本地记录，不会因为远程变化而消失，但会随时间过期。如果自己这边没有记录，越早联系可能拉取过该分支的同事越好。还原时最好新建一个临时分支做验证，确认 commit id 与预期一致后再强制推回。

被保护分支挡住时怎么办

有些远程仓库在服务器端开启了分支保护规则，比如要求 pull request 通过后才允许推送。此时执行 git push --force 会收到 protected branch hook declined 的报错，说明命令被服务端拦截。处理方式不是绕过，而是找管理员确认是否允许临时关闭保护，或者由管理员代为执行强制推送。另一种做法是先删除远程分支再推送：git push --delete origin 分支名，但这会丢失远程分支的关联状态，其他协作者重新 fetch 时可能出现引用混乱，不推荐作为常规手段。

强制推送不是一条逃生通道，而是需要收尾的操作。覆盖前把确认工作做完整，覆盖后尽快通知相关人更新引用，比赌运气要可靠得多。