Git branch diverged after rebase
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.
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.
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:
- main branch is develop
- You checkout a new branch feature/doing_stuff
- 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:
- git checkout feature/doing_stuff
- git rebase develop
- git checkout develop
- 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.