git 分支在 rebase 后出现分歧

Git branch diverged after rebase

提问by Marty Wallace

I have rebased a branch locally which was already pushed.

我在本地重新设置了一个已经推送的分支。

Git is advising that my branch and remote have diverged and that:

Git 建议我的分支和远程已经出现分歧，并且：

"and have 109 and 73 different commits each, respectively"

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

Will pushing my branch resolve this - i.e. is this to be expected after a rebase?

推动我的分支会解决这个问题 - 即在 rebase 后会出现这种情况吗？

回答by Jason LeBrun

When you rebase a branch, you have to rewrite the commits for any commit which is above the commits in the branch onto which you are rebasing. This is because one of the properties of a commit is its parent (or parents). When you rebase, you're changing the parent of the oldest local commit on your branch - and thus changing the commit hashes of all of your local commits, since this change bubbles up through the commits transitively.

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

Since you'd already pushed the branch, you should have merged in the source branch, rather than rebasing against it. It is possible to "force push" your new branch (using the -fflag), but a normal push won't work, because the integrity of the branches history will be disturbed. If you are collaborating with others on this branch, force pushing is a bad idea, as it will cause other collaborators to become very confused when their history suddenly doesn't match.

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

TL;DR - If you're not collaborating, push the branch using push -f. If you are, reset the branch to the previous state, and merge in the source branch, instead.

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

回答by mimoralea

All your commits have changed ids, so the diversion is not trulya diverge.

你所有的提交都改变了 id，所以转移并不是真正的分歧。

To get your problem resolvedyou have to overwrite your remote branch:

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

git push -f origin experiment

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

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

Explanation:

解释：

See how in this image C3 is not put as C3 after the rebase, but as C3'. This is because it is not exactly C3, but it has all of its code changes.

看看这张图片中的 C3 是如何在变基后不作为 C3 放置的，而是作为 C3' 放置的。这是因为它不完全是 C3，但它的所有代码都发生了变化。

On this other image you get the picture of what a rebase is seen when a remote is involved, and why there is a diversion.

在这张另一张图片上，您可以了解当涉及遥控器时会看到什么变基，以及为什么会发生转移。

In any case, after you do the forced push, it will tell you that it did a (force update), you should be fine at that point.

无论如何，在您执行强制推送后，它会告诉您它执行了（强制更新），此时您应该没问题。

Checkout the link at the top, and search for "git push --force". You will see a more detailed explanation.

查看顶部的链接，然后搜索“git push --force”。您将看到更详细的说明。

回答by zerocog

I had success with the rebase diverge for a push by doing the following:

通过执行以下操作，我在 rebase diverge 上取得了成功：

git checkout mybranch
git pull
git push origin mybranch

The pull resolved the diverge.

拉力解决了分歧。

BEFORE the pull

拉之前

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

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

PULL output

拉输出

Merge made by recursive. mypath/myfile.py | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-)

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

AFTER pull

拉后

Your branch is ahead of 'origin/mybranch' by 3 commits.

您的分支领先于 'origin/mybranch' 3 次提交。

AFTER PUSH

推后

mybranch is 3 ahead of the branch the still has an open pull request merge message added to the commit history Merge branch mybranch of remote into mybranch

mybranch 在分支之前 3 仍然有一个打开的拉取请求合并消息添加到提交历史中 将远程分支 mybranch 合并到 mybranch

I am assuming this is probably what the force push does, and I have not verified.

我假设这可能是 force push 所做的，我还没有验证。

As the others have said, avoid a rebase if you already have an open pull request. I am providing this example as something that worked for me.

正如其他人所说，如果您已经有一个开放的拉取请求，请避免 rebase。我提供这个例子作为对我有用的东西。

回答by Chris

This can be fixed without a force push by rebasing the target branch into your current local branch, switching to your target branch, and then rebasing your local branch into the target. This doesn't diverge since the commit(s) that may be missing are added and don't need to be created anymore. Example for easier explanation:

这可以通过将目标分支重新设置为当前本地分支、切换到目标分支，然后将本地分支重新设置为目标来解决，而无需强制推送。这不会发散，因为添加了可能丢失的提交并且不再需要创建。更容易解释的示例：

1. main branch is develop
2. You checkout a new branch feature/doing_stuff
3. A team member pushes a new commit to develop

1. 主要分支是develop
2. 你签出一个新的分支功能/doing_stuff
3. 一个团队成员推动一个新的提交来开发

If you have NOT updated your develop branch then a "git checkout develop" && "git rebase feature/doing_stuff" will work correctly since no commits have been added since your checkout. However, if you have checked out develop and pulled down the new commit then you will see this divergence if you try to rebase due to a new commit being seen. An easy fix without force pushing (usually not a good idea in a team environment) is to:

如果您还没有更新您的开发分支，那么“git checkout develop”&&“git rebase feature/doing_stuff”将正常工作，因为自您结帐以来没有添加任何提交。但是，如果您已经检查了 develop 并拉下了新的提交，那么如果您由于看到新的提交而尝试变基，您将看到这种分歧。无需强制推送的简单解决方案（在团队环境中通常不是一个好主意）是：

1. git checkout feature/doing_stuff
2. git rebase develop
3. git checkout develop
4. git rebase feature/doing_stuff

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

The rebase from step 2 brings the missing commit into the feature/doing_stuff so when step 4 comes along it is up to date and does not need to create a new commit for the change.

第 2 步的 rebase 将丢失的提交带入 feature/doing_stuff，因此当第 4 步出现时，它是最新的，不需要为更改创建新的提交。

This is a solution that I know works because I just ran into this and did the steps above to successfully push develop without forcing. I work in a team of over 50 developers so it is forbidden to force push anything other than my own testing branches so I had to find a resolution.

这是一个我知道有效的解决方案，因为我刚刚遇到了这个问题并执行了上述步骤以成功推动开发而无需强制。我在一个由 50 多名开发人员组成的团队中工作，因此禁止强制推送除我自己的测试分支之外的任何内容，因此我必须找到解决方案。