git push和git push -f之间的区别

Question

有人可以帮我解释一下git push和git push -f之间的区别吗？ 我不知道建议在github上推送你的文件中的哪一个

Answer 1

git push -f是git push --force的缩写。它会强制推送，否则git会拒绝您的git push，因为您在推送存储库中更改了repo历史记录。 （编辑：但这只是故事的一半。强迫推送也会让你覆盖其他人的提交，这些提交在你上一次拉动后被推动。）使用案例：

1. 您的存储库位于提交A.您在本地更改某些内容并提交它（提交B）。
2. 您将B推送到远程仓库。两人现在都在B。
3. 您决定再次更改内容，并通过提交B＆＃39;。
替换您的提交B.
4. 你想推动你的承诺B＆＃39;到远程存储库。简单的git push将无效。您现在可以从远程仓库中删除提交B并按下B＆＃39;而是使用git push --force。

没关系，只要你使用那个远程仓库（或者其他一些没有在B和B之间拉动的人）。所以，不，不是github上的好主意。

希望有所帮助。

（编辑：您还可以查看GIT documentation或GitHub help）

Answer 2

您可以使用git help [command]获取每个git命令的帮助。这是push的提取，更特别是选项-f：

  

-f， - force

     

通常，该命令拒绝更新远程ref，该远程ref不是用于覆盖它的本地ref的祖先。此外，当使用--force-with-lease选项时，该命令拒绝更新当前值与预期值不匹配的远程ref。

     

此标志禁用这些检查，并可能导致远程存储库丢失提交;小心使用它。

我做了这个例子是为了更好地解释它：

在步骤1），Alice和Bob共享相同的历史记录，该历史记录与原始文件保持同步。

然后，Alice添加一个提交并将其推送到git push（步骤2）。这是有效的，因为提交C）具有提交B）作为祖先。

然后，Bob在提交B）之后在其本地分支上添加提交D），然后尝试用git push推送它（步骤3）。

这是无效的：

• 在Bob的分支上，D的祖先应该是B.
• On Origin，B已经有一个不是D =＆gt;的后继者。冲突。

鲍勃可以（但不会）使用git push -f用A-B-D替换起源的历史记录。这很糟糕，因为它会破坏爱丽丝的历史，其中B的继承者仍然是C.

Bob 必须在本地获取提交C（使用git fetch）然后在本地解决冲突（使用git merge或git rebase）然后推送结果（与git push）

Answer 3

不同之处在于git push -f告诉git尝试“强制”推送。具体做法是：

推送是更新远程引用的请求，以反映本地引用的状态。默认情况下，仅当本地引用是远程引用的后代时（即，如果远程引用可通过父指针从本地引用访问），则仅允许此操作。这是分支增长的常规方式，它允许其他用户将添加的提交解释为基于他们已经在分支上看到的提交构建的新版本。例如，如果你有

A -- B -- C <--(origin/master)
           \
            D -- E <--(master)

您可以推送此内容，每个人都会将其解释为“D和E已添加到master”（或多或少）。

有时您可能希望以违反此规则的方式移动分支引用。通常这意味着您已编辑过历史记录（但请参阅下面的警告）。假设你有

A -- B -- C <--(origin/master)
 \
  BC -- D <--(master)

在这张图片中，您可能会将B和C“压缩”为一次提交，然后添加提交D。默认情况下，git会拒绝尝试这样的推送; -f（或--force）选项告诉它尝试。请注意，服务器可能配置为拒绝强制推送。

这引出了我提到的警告：如果你执行强制推送，从ref的历史记录中删除提交（B和C），并且如果其他人有一个克隆，那么相应的ref的历史记录包括已删除的提交，它们将处于损坏的状态（如果它们执行“错误的操作”以恢复，它们将撤消您的工作）。因此，与受影响的其他用户协调任何历史记录编辑非常重要。有关详细信息，请参阅git rebase文档中的“从上游rebase中恢复”。

所以回答你的问题：以上是他们的不同之处，建议的做法是通常 git push，只使用{{ 1}}当（a）你需要它的具体原因时，和，（b）你得到任何受影响的人的同意。

Answer 4

git push -f是一个强制推送，意味着所有更改都被强制进入回购。我建议只使用git push，因为它可能会强制你不想要的更改。