git推--强制租赁vs. .

Question

我试着去理解

git push --force

和

git push --force-with-lease

我的猜测是，只有当遥控器提交了本地分支没有的提交时，后者才会推到远程。

Answer 1

force用本地分支覆盖远程分支。

--force-with-lease是一个更安全的选项，如果向远程分支添加了更多的提交(由其他团队成员或同事或其他什么东西添加)，则不会覆盖远程分支上的任何工作。它可以确保你不会用武力来覆盖别人的工作。

我认为你对命令的总体看法是正确的。如果远程分支与本地计算机上的远程分支具有相同的值，则将覆盖remote。如果它没有相同的值--它表示在您处理代码时其他人对远程分支所做的更改，因此不会覆盖任何代码。显然，如果远程中有额外的提交，那么值就不一样了。

当我想确保不覆盖任何队友代码时，我只是把--force-with-lease看作是一种可以使用的选项。我公司的很多团队都使用--force-with-lease作为默认的防故障选项。这在大多数情况下都是不必要的，但如果你碰巧覆盖了另一个人对远程的贡献，你就会省去很多头痛。

我相信你看过这些文档，但这里可能包含了一些更冗长的解释：

https://git-scm.com/docs/git-push

Answer 2

git push --force具有破坏性，因为它无条件地用本地的任何内容覆盖远程存储库。git的push --force被强烈禁止，因为它可以破坏其他已经被推送到共享存储库的提交。力的推动最常见的原因之一是当我们被迫重新建立分支的时候。

例如。我们有一个带有特性分支的项目，Alice和Bob都将在其中工作。他们都克隆了这个存储库并开始工作。Alice最初完成了她的部分功能，并将其推上主存储库。这一切都很好，很好。Bob也完成了他的工作，但在推上之前，他注意到一些更改已经合并到master中。为了保持一棵干净的树，他在主树枝上做了一次调整。当然，当他去推动这个重新建立的分支的时候，它会被拒绝。然而，没有意识到爱丽丝已经推动了她的工作，他执行了一种推动力量。不幸的是，这将删除Alice在中央存储库中更改的所有记录。

--force-with-lease所做的是拒绝更新分支，除非它是我们所期望的状态；也就是说，没有人向上游更新分支。在实践中，这是通过检查上游引用是否是我们所期望的，因为ref是散列，并且隐式地将父链编码到它们的值中。

这里有一个关于git push --force和git push --force-with-lease的很好的帖子：-force认为是有害的；理解git‘s-强制租赁

Answer 3

假设服务器上的任何预接收钩子都接受推送，这将始终成功：

git push --force

然而，在继续之前，这会运行特定的客户端检查：

git push --force-with-lease

您可以手动运行特定的检查。下面是“租约检查”算法：

1. 算出你现在的分支。
2. 运行git for-each-ref refs/remotes。请注意git客户端认为对应于当前分支的上游状态的提交id。

例如，如果您在分支"foo“上，请注意与”refs/remotes/ branch /foo“相关的提交id。

1. 现在就确定上游git服务器上远程分支的实际提交id。
2. 只有当您从步骤2和步骤3提取的提交if一致时，才让"git推送“继续进行。换句话说，只有当本地git克隆人的上游概念与实际上游一致时，才能继续进行。

这里有一个令人悲哀的含义:由于git fetch将所有refs /remotes/origin/*下的refs更新到其最新版本，这种命令的组合与git push --force本质上是相同的。

git fetch

# The command below behaves identically to "git push --force"
# if a "git fetch" just happened!

git push --force-with-lease

为了解决git push --force-with-lease中这个固有的弱点，我尝试不运行git fetch。相反，每当需要与上游同步时，我总是运行git pull --rebase，因为git pull只更新参考/远程下面的单个引用，从而使--force-with-lease的“租约”非常有用。