Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

after git rebase my local branch and remote branch have diverged

I have a my-feature branch that is pushed up to origin for code review. It is not shared. Eventually it will get merged into my develop branch which is shared amongst my team. I'd like to rebase my develop branch into my-feature to keep the history cleaner and then merge my feature branch into develop. This is what I have been doing:

$ git checkout my-feature
// do some work. make commits.

$ git rebase develop
// fix some conflicts

$ git add .

$ git rebase --continue

After I have rebased successfully, I check the status:

$ git status
On branch my-feature
Your branch and 'origin/my-feature' have diverged,
and have 155 and 1 different commit each, respectively.
  (use "git pull" to merge the remote branch into yours)

$ git what do I do here?

I have to idea what to do here. If I git pull, then I've noticed that I will get some conflicts which doesn't make sense. Some people say to force push but I'm nervous about that. Is it normal to force push my topic branch to origin? So long as no one else uses that branch?

like image 502
Jeff Avatar asked Nov 19 '15 22:11

Jeff


People also ask

Why is git branch diverged?

A branch in git is a series of interrelated commits. If two branches follow a non-linear path then they diverge each other.

How do I reset a diverged branch?

Sometimes a branch has diverged from origin so much, that it doesn't make sense to try to resolve all the conflicts. In this case, it's better to just reset your local branch to whatever is on origin. To do this, you need to fetch first and then run git reset --hard origin/<branch> .

Does git rebase affect the remote repository?

No, locally rebasing doesn't change the remote. @jonrsharpe So basically, I have to push to remote branch again after the rebase?


2 Answers

First, you can do a git push --force at this stage without any worries: you have said your branch is not shared.
So changing its history on the server side won't affect any other user.

Second, when you rebase a branch, you change its common ancestor from with its remote tracking branch (origin/xxx)

Before git rebase develop, you have

d--d--d (develop)
    \
     x--x--x--x--x--X--y--y--y (my-feature)
                    |
       (origin/my-feature)   

X is the common ancestor between origin/feature and feature, which simply means you have added a few commits in your my-feature branch).
A git status would return something like:

On branch my-feature
Your branch is ahead of 'origin/my-feature' by 3 commit.

But when you rebase that branch on top of develop, you replay all the commits of my-feature on top of develop HEAD

        X--X--X--X--X--X--Y--Y--Y  (my-feature)
       /
d--D--d (develop)
    \
     x--x--x--x--x--X
                    |
       (origin/my-feature)   

This time, the common ancestor between my-feature and origin/my-feature no longer is a few added commit, but the full history of my-feature, plus some commits of develop! (D here)

Hence the status

Your branch and 'origin/my-feature' have diverged,
and have 155 and 1 different commit each, respectively.

Since your branch isn't shared, again, a simple git push --force origin my-feature will complete the operation:

        X--X--X--X--X--X--Y--Y--Y  (my-feature, origin/my-feature)
       /
d--D--d (develop)

(If my-feature has an upstream branch, a git push --force is enough, provided the default push policy push.default is set to simple.
Check that with git rev-parse --abbrev-ref --symbolic-full-name @{u})

like image 62
VonC Avatar answered Sep 19 '22 08:09

VonC


What you're seeing is that my-feature is indeed different than origin/my-feature (what my-feature looked like on origin the last time you checked) because you just changed my-feature (the my-feature you're working with) when you did the rebase.

When you do a rebase, you're changing the history of a branch so you'll almost always need to --force push afterwards. It's fine if it's your branch and there aren't any collaborators using that branch.

If this feature branch does have collaborators, then you shouldn't have rebased to begin with. General rule of thumb is to not alter the history of shared branches. If this is the case, you'll need to undo the rebase, which you can refer to this post for help with.

like image 37
jaredready Avatar answered Sep 17 '22 08:09

jaredready