Git branch diverged after rebase

I have rebased a branch locally which was already pushed.

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

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

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

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.

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 -f flag), 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.

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.

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

To get your problem resolved you have to overwrite your remote branch:

git push -f origin experiment

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.

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.

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

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.

PULL output

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

AFTER pull

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

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

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

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.

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

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:

1. git checkout feature/doing_stuff
2. git rebase develop
3. git checkout develop
4. git rebase feature/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.

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.