作为开发者，您很可能经历过这种情况：刚发现上一次提交里的代码有问题。为撤销这个失误，您运行了一些命令并重写了本地历史。随后执行 git push --force 想把一切清理干净，却被队友告知有些提交不见了，或者流水线出现了构建失败。
本文将带您了解 git push --force 的实际作用、适用场景，以及如何避免出错。如果您刚开始使用 Git，建议先学习 我们的Introduction to Git 课程以掌握版本控制的基础。此外，我也推荐可下载的 Git Cheat Sheet 速查表，涵盖最常见的 Git 术语与命令，查阅十分方便。
何时您会觉得需要使用 git push --force
假设您在推送前准备清理本地提交历史。为在合并前梳理提交，您运行 git rebase -i main。本地一切看起来很完美，于是尝试用一个简单的 git push 更新远程分支。但 Git 却没有给出常见的成功消息，而是报错。
还有一种情况，您不小心提交 了敏感数据，比如 API 密钥或密码，并且已经推送到了远程。在本地重写历史移除问题提交后，您发现正常推送并不会更新远程仓库，敏感数据仍然存在，取而代之的是一条错误信息。
! [ rejected] main -> main ( non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes ( e.g.,
hint: 'git pull ...' ) before pushing again.技术支持 这个“non-fast-forward”（非快进）错误是 Git 的安全网，提醒您本地历史与服务器上的不一致。此时，您可能会想用 git push --force 来绕过这个错误。
如果仅您一人在该分支上工作，这么做或许问题不大。但在共享项目中，这很容易引发混乱，甚至删掉他人的工作成果。
git push --force 的实际作用
通常，只有当您的本地分支包含远程已有的一切内容（再加上您的新提交）时，Git 才允许推送。然而，有时您会通过 git rebase、 压缩（squash）提交 或移除敏感数据来重写提交历史。这样一来，本地分支就与远程分支不同了。当您再尝试推送新提交时，Git 会报错，以保护远程分支免遭工作内容丢失。
使用 git push --force 是告诉 Git 跳过安全检查，用您本地分支的内容覆盖远程分支。
命令如下所示：
git push --force origin main技术支持 这会将远程的 main 分支更新为与您本地 main 一致，并删除本地分支中不存在的远程提交。
可以把您的 Git 分支想象成团队合写的一本书中的一个章节。标准的 push 就像在章节末尾添加新段落；而 git push --force 的能力更强，像是把当前章节整章撕下，完全换成您的版本。
使用 git push --force 的风险在于：如果协作者基于您刚刚删除的提交开展了工作，他们的成果可能会丢失。下一节我们将看看使用 --force 时应采取的预防措施。
为何这会“搞崩”整个团队
如果您强制推送到 main 或 develop 这样的共享分支，很可能会遇到以下情况：
他人的本地分支与远程失去同步： 如果队友已拉取了您现在从远程抹掉的旧提交，他们的本地历史将不再与服务器匹配。本地分支会引用“消失”的提交，造成混乱。 拉取会引发令人困惑的合并或错误： 当他人在您强制推送后尝试 git pull ，Git 无法将重写过的历史与他们本地的提交序列对齐。往往会出现奇怪的合并提交、晦涩的错误，或者需要队友手动使用 git fetch、git reset，甚至重新克隆分支。 CI/CD 流水线可能失败： 流水线通常依赖一致的提交哈希和线性历史。强制推送可能导致它们测试失败、重新部署错误的代码，或在基于过时提交重建时崩溃。
欢迎学习我们的 CI/CD for Machine Learning 课程，了解如何构建 CI/CD 工作流。我也推荐我们的 Introduction to Data Versioning with DVC 课程，了解数据版本管理与代码版本管理的区别。
举个例子：您与一位队友都在 feature 分支上工作。 您先清理 了本地历史，然后执行 git push --force。几分钟后，队友推送了他们的更改，结果在 Git 中看到错误。拉取时又遭遇合并冲突，提交历史也被搅乱。与此同时，CI 流水线因为缺少提交而失败。现在，队友不得不花时间理顺分支，部署也被延误。
一次强制推送，就可能引发这些连锁反应。
更安全的选择：git push --force-with-lease
为避免上述问题，我建议使用 git push --force-with-lease。此命令在推送到远程分支时添加安全检查，以避免意外提交被覆盖。
git push --force-with-lease origin main技术支持 可以把 --force-with-lease 理解为“在跳下去之前先确认周围是否安全”。在执行任何操作前，它会确认是否没有其他人更改过该分支。如果一切与您上次看到的一样，就会更新历史；但如果出现了您未知的新变更，Git 会阻止推送并提示您先进行审查。这样就能始终保护协作者，避免无意覆盖。
如何从一次错误的强制推送中恢复
即使丢失了一些提交，也不必担心，仍然可以恢复。Git 始终会记录对当前提交所做的变更（包括重写），并将其存储在 reflog 中。
以下是恢复丢失提交的方法：
步骤 1：使用 git reflog 查找丢失的提交
运行 git reflog 查看您的分支历史。
git reflog技术支持 您可能会看到类似如下的记录：
abc1234 HEAD@{ 1 } : push: force push
def5678 HEAD@{ 2 } : commit: add new feature技术支持 步骤 2：还原丢失的提交
确定要恢复的提交哈希后，使用下列命令切换到该特定提交。
git checkout def5678技术支持 步骤 3：创建新分支
为安全恢复文件，请创建一个新的 git 分支 。
git checkout -b recovery-branch技术支持 步骤 4：恢复远程分支
现在将恢复的提交推送到分支：
git push origin recovery-branch技术支持 请注意，reflog 数据只存在于本地机器上。因此，如果您的队友当中没有人在本地环境中保存了这些提交，可能就无法恢复它们。
想进一步了解 Git 中的协作与分支操作，推荐学习我们的 Intermediate Git 课程。
安全使用 git push --force 的最佳实践
为尽量降低风险，建议养成以下习惯：
优先使用 --force-with-lease 而非 --force ：这是一种更安全的方式，会检查自您上次 fetch 之后远程分支是否未发生变化。可以帮助保护队友，避免意外覆盖。
避免向共享分支强制推送： 切勿对 main、master、develop 或 release 等共享分支执行强制推送。只对您个人维护的功能分支执行强制推送，以免造成干扰。
在强制推送前通知团队： 如果确实必须对共享分支进行强制推送，请事先告知团队。这能让他们保存工作，避免丢失。
使用受保护分支： 在 GitHub、GitLab、Bitbucket 等平台上启用分支保护。它会限制直接编辑，防止对重要分支的意外强制推送。
如果您想进一步了解如何管理私有仓库，请查 看我们的 Introduction to GitHub Concepts 课程，了解在 GitHub 上协作时如何评审拉取请求。
结论
git push --force 为重写仓库历史提供了有用的方法，无论是清理提交，还是移除敏感数据。但在使用该命令时务必谨慎，避免破坏团队的工作流程。
在可能的情况下，优先使用 --force-with-lease。它能在不冒险影响他人工作的前提下，给予您更多可控性。通过细致操作与及时沟通，您可以在不干扰团队的情况下保持 Git 历史整洁。
建议您查看我们的 Git Fundamentals 与 GitHub Foundations 技能路径，全面提升 Git 相关能力。
%22%3E%3Cpath%20d%3D%22m-369%200h408v79h-408z%22%20fill%3D%22%237933ff%22%2F%3E%3Cpath%20d%3D%22m-148%200h306v45h-306z%22%20fill%3D%22%23974dff%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
%22%2F%3E%3C%2FclipPath%3E%3Cg%20clip-path%3D%22url(%23a)%22%3E%3Cpath%20d%3D%22m76%200h484v36h-484z%22%20fill%3D%22%23974dff%22%2F%3E%3Cpath%20d%3D%22m0%200h384v24h-384z%22%20fill%3D%22%2306bdfc%22%20transform%3D%22matrix(1%200%200%20-1%200%2060)%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
作为开发者，您很可能经历过这种情况：刚发现上一次提交里的代码有问题。为撤销这个失误，您运行了一些命令并重写了本地历史。随后执行
git push --force想把一切清理干净，却被队友告知有些提交不见了，或者流水线出现了构建失败。本文将带您了解
git push --force的实际作用、适用场景，以及如何避免出错。如果您刚开始使用 Git，建议先学习我们的Introduction to Git 课程以掌握版本控制的基础。此外，我也推荐可下载的 Git Cheat Sheet 速查表，涵盖最常见的 Git 术语与命令，查阅十分方便。何时您会觉得需要使用 git push --force
假设您在推送前准备清理本地提交历史。为在合并前梳理提交，您运行
git rebase -i main。本地一切看起来很完美，于是尝试用一个简单的git push 更新远程分支。但 Git 却没有给出常见的成功消息，而是报错。还有一种情况，您不小心提交了敏感数据，比如 API 密钥或密码，并且已经推送到了远程。在本地重写历史移除问题提交后，您发现正常推送并不会更新远程仓库，敏感数据仍然存在，取而代之的是一条错误信息。
这个“non-fast-forward”（非快进）错误是 Git 的安全网，提醒您本地历史与服务器上的不一致。此时，您可能会想用
git push --force来绕过这个错误。如果仅您一人在该分支上工作，这么做或许问题不大。但在共享项目中，这很容易引发混乱，甚至删掉他人的工作成果。
git push --force 的实际作用
通常，只有当您的本地分支包含远程已有的一切内容（再加上您的新提交）时，Git 才允许推送。然而，有时您会通过
git rebase、压缩（squash）提交或移除敏感数据来重写提交历史。这样一来，本地分支就与远程分支不同了。当您再尝试推送新提交时，Git 会报错，以保护远程分支免遭工作内容丢失。使用
git push --force是告诉 Git 跳过安全检查，用您本地分支的内容覆盖远程分支。命令如下所示：
这会将远程的 main 分支更新为与您本地 main 一致，并删除本地分支中不存在的远程提交。
可以把您的 Git 分支想象成团队合写的一本书中的一个章节。标准的 push 就像在章节末尾添加新段落；而
git push --force的能力更强，像是把当前章节整章撕下，完全换成您的版本。使用
git push --force的风险在于：如果协作者基于您刚刚删除的提交开展了工作，他们的成果可能会丢失。下一节我们将看看使用--force时应采取的预防措施。为何这会“搞崩”整个团队
如果您强制推送到
main或develop这样的共享分支，很可能会遇到以下情况：欢迎学习我们的 CI/CD for Machine Learning 课程，了解如何构建 CI/CD 工作流。我也推荐我们的 Introduction to Data Versioning with DVC 课程，了解数据版本管理与代码版本管理的区别。
举个例子：您与一位队友都在
feature分支上工作。您先清理了本地历史，然后执行git push --force。几分钟后，队友推送了他们的更改，结果在 Git 中看到错误。拉取时又遭遇合并冲突，提交历史也被搅乱。与此同时，CI 流水线因为缺少提交而失败。现在，队友不得不花时间理顺分支，部署也被延误。一次强制推送，就可能引发这些连锁反应。
更安全的选择：git push --force-with-lease
为避免上述问题，我建议使用
git push --force-with-lease。此命令在推送到远程分支时添加安全检查，以避免意外提交被覆盖。可以把
--force-with-lease理解为“在跳下去之前先确认周围是否安全”。在执行任何操作前，它会确认是否没有其他人更改过该分支。如果一切与您上次看到的一样，就会更新历史；但如果出现了您未知的新变更，Git 会阻止推送并提示您先进行审查。这样就能始终保护协作者，避免无意覆盖。如何从一次错误的强制推送中恢复
即使丢失了一些提交，也不必担心，仍然可以恢复。Git 始终会记录对当前提交所做的变更（包括重写），并将其存储在reflog 中。
以下是恢复丢失提交的方法：
步骤 1：使用 git reflog 查找丢失的提交
运行
git reflog查看您的分支历史。您可能会看到类似如下的记录：
步骤 2：还原丢失的提交
确定要恢复的提交哈希后，使用下列命令切换到该特定提交。
步骤 3：创建新分支
为安全恢复文件，请创建一个新的 git 分支。
步骤 4：恢复远程分支
现在将恢复的提交推送到分支：
请注意，reflog 数据只存在于本地机器上。因此，如果您的队友当中没有人在本地环境中保存了这些提交，可能就无法恢复它们。
想进一步了解 Git 中的协作与分支操作，推荐学习我们的 Intermediate Git 课程。
安全使用 git push --force 的最佳实践
为尽量降低风险，建议养成以下习惯：
优先使用 --force-with-lease 而非 --force：这是一种更安全的方式，会检查自您上次 fetch 之后远程分支是否未发生变化。可以帮助保护队友，避免意外覆盖。
避免向共享分支强制推送：切勿对
main、master、develop或release等共享分支执行强制推送。只对您个人维护的功能分支执行强制推送，以免造成干扰。在强制推送前通知团队：如果确实必须对共享分支进行强制推送，请事先告知团队。这能让他们保存工作，避免丢失。
使用受保护分支：在 GitHub、GitLab、Bitbucket 等平台上启用分支保护。它会限制直接编辑，防止对重要分支的意外强制推送。
如果您想进一步了解如何管理私有仓库，请查看我们的 Introduction to GitHub Concepts 课程，了解在 GitHub 上协作时如何评审拉取请求。
结论
git push --force为重写仓库历史提供了有用的方法，无论是清理提交，还是移除敏感数据。但在使用该命令时务必谨慎，避免破坏团队的工作流程。在可能的情况下，优先使用
--force-with-lease。它能在不冒险影响他人工作的前提下，给予您更多可控性。通过细致操作与及时沟通，您可以在不干扰团队的情况下保持 Git 历史整洁。建议您查看我们的 Git Fundamentals 与 GitHub Foundations 技能路径，全面提升 Git 相关能力。