在rebase之后，Git分支出现了分歧

Question

我已在本地修改了一个已推出的分支。

Git建议我的分支和远程分歧并且：

“并分别拥有109和73个不同的提交”

推动我的分支会解决这个问题 - 也就是说，这是在一次重组之后预期的吗？

Answer 1

当你重新分支一个分支时，你必须重写任何提交的提交，该提交位于你正在重新定位的分支中的提交之上。这是因为提交的一个属性是其父（或父）。当您进行rebase时，您正在更改分支上最旧的本地提交的父级 - 从而更改所有本地提交的提交哈希值，因为此更改会通过提交传递过来。

由于您已经推送了分支，因此您应该在源分支中合并，而不是对其进行重新绑定。可以“强制推送”新分支（使用-f标志），但正常推送不起作用，因为分支历史记录的完整性将受到干扰。如果你在这个分支上与其他人合作，强制推送是一个坏主意，因为当他们的历史突然不匹配时，它会导致其他合作者变得非常困惑。

TL; DR - 如果您没有合作，请使用push -f推送分支。如果是，请将分支重置为先前的状态，然后在源分支中合并。

Answer 2

您的所有提交都已更改了ID，因此转移并非真正分歧。

要解决问题，您必须覆盖远程分支：

git push -f origin experiment

http://git-scm.com/book/ch3-6.html

<强>解释

看看在这个图像中C3如何在rebase之后不作为C3放置，而是作为C3＆＃39;。这是因为它不完全是C3，但它具有所有代码更改。

在另一张图片上，您可以看到当涉及遥控器时看到什么样的底板，以及为什么会有转移。

在任何情况下，在你进行强制推送之后，它会告诉你它执行了（强制更新），那时你应该没事。

查看顶部的链接，然后搜索＆＃34; git push --force＆＃34;。您将看到更详细的解释。

Answer 3

可以通过以下方法解决此问题：将目标分支重新部署到当前本地分支，切换到目标分支，然后将本地分支重新部署到目标。这不会发散，因为添加了可能丢失的提交，并且不再需要创建。为了更容易解释的示例：

1. 主分支是 develop
2. 您签出一个新分支功能/功能
3. 团队成员推送新的承诺以进行开发

如果您尚未更新自己的develop分支，那么“ git checkout开发”和＆“ git rebase功能/ doing_stuff”将正常工作，因为自从签出以来未添加任何提交。但是，如果您签出了development并撤消了新的提交，那么由于尝试看到新的提交而尝试重新设置基准时，您将看到这种差异。一个简单的解决方法，而无需用力推动（在团队环境中通常不是一个好主意）是：

1. git checkout 功能/功能
2. git rebase 开发
3. git checkout 开发
4. git rebase 功能/功能

第2步中的重新存储将缺少的提交提交到feature / doing_stuff中，因此当第4步进行时，它是最新的，不需要为更改创建新的提交。

我知道这是一个有效的解决方案，因为我只是碰到了这个问题，并且执行了上面的步骤来成功地推动开发而无需强迫。我的团队由50多个开发人员组成，因此除我自己的测试分支外，禁止强加任何其他操作，因此我必须找到解决方法。

Answer 4

通过执行以下操作，我成功实现了rebase差异的推动：

git checkout mybranch
git pull
git push origin mybranch

拉力解决了分歧。

拉动之前

Your branch and 'origin/mybranch' have diverged,
and have 2 and 1 different commit(s) each, respectively.

PULL输出

  

通过递归合并。 mypath / myfile.py | 12   +++++++++++-已更改1个文件，11个插入（+），1个删除（-）

拉后

  

您的分支比'origin / mybranch'提前3次提交。

推后

  

mybranch在分支之前3，仍然有一个开放请求请求   将合并消息添加到提交历史记录中将远程分支mybranch合并到mybranch

我假设这可能是推力所做的，但我尚未验证。

正如其他人所说，如果您已经有一个开放的拉取请求，请避免重新设置基准。我提供的这个示例对我有用。