功能分支重新绑定后，Git推送被拒绝

好吧，我认为这是一个简单的混帐场景，我错过了什么？

我有一个master分支和一个feature分支。 我做了一些关于master工作，一些关于feature ，然后一些关于master 。 我最终得到了类似这样的东西（词典顺序意味着提交顺序）：

A--B--C------F--G  (master)
           
        D--E  (feature)

我没有问题git push origin master让远程master更新，也没有与git push origin feature （就当feature ），以保持我的远程备份feature的工作。 到目前为止，我们很好。

但现在我想重订feature在上面F--G上主承诺，所以我git checkout feature和git rebase master 。 还好。 现在我们有：

A--B--C------F--G  (master)
                 
                  D'--E'  (feature)

问题：当我想备份使用git push origin feature feature分支的新基础feature ， 推送被拒绝，因为树由于重新绑定而发生更改。 这只能通过git push --force origin feature来解决。

我讨厌使用--force而不确定我需要它。 那么，我需要它吗？ 请问垫底一定意味着未来push应该是--force FUL？

这个功能分支不与任何其他开发人员共享，所以我在强制推送时事实上没有问题，我不会丢失任何数据，问题更具概念性。

---

问题是git push假定远程分支可以被快速转发到你的本地分支，也就是说，本地和远程分支之间的所有差异在本地都有一些新的提交，就像那样：

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
               
        T--Y    <- some-branch

当你执行git rebase commit时，D和E被应用到新的基础上并创建新的提交。 这意味着rebase之后你有这样的东西：

A--B--C------F--G--D'--E'   <- feature-branch
         
        D--E                <- origin/feature-branch

在这种情况下，远程分支不能被快速转发到本地。 虽然，理论上本地分支可以合并到远程（显然，在这种情况下你不需要它），但是由于git push只执行快速合并，它会抛出错误。

而且--force选项所做的只是忽略远程分支的状态，并将其设置为您要推入的提交。 因此， git push --force origin feature-branch只需使用本地feature-branch覆盖origin/feature-branch feature-branch 。

在我看来，只要您是唯一一个在该分支上工作的人，在master上重新设置功能分支并强制将其推回到远程存储库即可。

---

而不是使用-f或--force开发人员应该使用的

--force-with-lease

为什么？ 因为它检查远程分支的变化，这绝对是一个好主意。 让我们想象一下James和Lisa正在制作相同的功能分支，Lisa推送了一个提交。 詹姆斯现在重新设置他的本地分支，并在尝试推进时被拒绝。 当然詹姆斯认为这是由于rebase和使用 - 力，并会重写所有Lisa的变化。 如果詹姆斯使用“强制租赁”的方式，他会收到一个警告，说有人提交了一些提交。 我不明白为什么有人会在推出rebase之后使用--force而不是--force-with-lease。

---

我会用“checkout -b”来代替，它更容易理解。

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

当您删除时，您可以阻止推入包含不同SHA ID的退出分支。 在这种情况下，我只删除远程分支。

链接地址: http://www.djcxy.com/p/1355.html

上一篇: Git push rejected after feature branch rebase

下一篇: How to squash commits in git after they have been pushed?