为什么/什么时候应该强迫推？

Question

我经常阅读有关如何强制推送的信息，以及未拉动的远程存储库中的所有提交都会丢失。 如果一个人不需要特定的提交，他也可以创建一个新的分支，这在我看来更常见，因为你不会丢失数据，即使你现在不需要特定的代码或其他什么，也许你将来需要它，我认为没有理由破坏它。

所以我的问题是我有什么理由可以强行推动？

Answer 1

  

我经常阅读有关如何强制推送的内容，以及未拉动的远程存储库中的所有提交都会丢失

不完全是：旧提交仍为referenced in the git reflog 即使您强制推送到GitHub，您仍然可以看到（作为repo所有者）前一个分支HEAD SHA1被新历史记录覆盖。请参阅“Does GitHub remember commit IDs?” 或者你have to contact GitHub support。

  

所以我的问题是我有什么理由可以强行推动？

无论何时你是唯一一个在分支机构工作的人（或者在一个仓库上，在叉子的情况下），你可以强制推动。
这是common in case of a Pull Request，其中Web GUI足够智能，可以自我更新以考虑新的历史记录：您可以强制推送自己的分支（再次假设您是唯一正在处理它的人） upstream/master的上游（上游是分叉的原始仓库）
这是triangular workflow。

的一部分

OP bpoiss添加in the comments：

  

VonC在他的回答中提到数据在强制推送后仍然存在，所以你无法删除敏感信息，或者我错过了什么？

要删除远程仓库上的敏感信息，您需要在远程服务器端执行一些命令：

$ git reflog expire --expire=now --all
$ git gc --prune=now

^{（来源：Remove sensitive data）}

这意味着，在将敏感数据推送到GitHub时，you have to contact GitHub support。

Answer 2

我遇到的常见原因是这种情况：

• github上的主回购
• 也在github上分叉
• 本地克隆

工作在本地发生，然后被推到分支。然后创建拉取请求，并提供用于代码审查。代码审查发现nits（拼写错误等），从长远来看，它们作为单独的提交无用。代码审查过程包括注释，然后是小修复提交，直到审阅者满意为止。

为了在主仓库中提供更合理的一组长期提交，开发人员然后使用rebase来减少pull请求中的提交集（通常为1），强制推送到fork，然后当测试变为绿色时，将其合并到主仓库中。

基本上，这依赖于仅用于 的分叉进行代码审查。它会对任何分叉的人造成严重破坏，但期望不会发生这种情况。

Answer 3

Git做了很多以确保你不会以一种你并不完全清醒的方式覆盖[其他人的]历史。也就是说，如果你有一个远程跟踪分支并且通过git filter-branch或git rebase更改历史记录，默认情况下Git不会让你推送它，因为历史记录没有排队

通过强制推送，你告诉Git你知道你在做什么，它会相信你的判断。也就是说，Git将不再握住您的手，它将允许您覆盖最初保护的引用。

我遇到的唯一有效方案是：

• 重新定位分支时（通过git rebase <branch>或git rebase -i HEAD~12）;如果没有它，你将无法保存rebase的工作
• 通过git filter-branch
等工具通过app.debug = True app.run() 或潜在修改大量历史记录时

强行推送任何其他上下文可能会非常危险。由于Git假设您在强制执行操作时知道自己在做什么，因此您有机会失去历史

Answer 4

最常见的原因是您将敏感数据推送到远程存储库。但是，如果其他人在您被迫推动之前撤离，他仍然可以访问您的私人数据。