Merge conflicts rebase

Question

So I had several commits in my local branch that were all about feature X. I rebased these commits without pulling from my remote branch into one commit - "Add feature X". Then when pulling from my remote branch I noticed duplicate commits. Commits that I had already squashed into one were now back. I thought OK, I'll just merge them and squash them into the "Add feature X" commit. The merging was fine. But when I tried rebasing I got tons of merge conflicts--most the same I had already resolved when I created the "Add feature X" commit. Dejected, I truged through it again (using git rebase -i and fixing all the conflicts) until the rebase was done. Now when I pulled from my remote I expected nothing to happen, but suprisingly all the same commits from the rebase were back again.

I don't understand what's happening. All I can think is I need to undo the rebases with git reset --hard commit-before-initial-rebase followed by git-pull and then try the rebase again.

What did I do wrong and how can I fix this?

Answer 1

The problem is that you've pushed commits to the remote branch, and then re-written history on your local branch.

After you've made changes locally, and pushed them to the remote branch, your local and remote branches look like this:

local:

--o--o--a--b--c
     ^        ^
     master   branch

remote:

--o--o--a--b--c
     ^        ^
     master   branch

So then you rebase and squash all the commits on the local branch, your local branch now looks like this:

local:

--o--o--d
     ^  ^
     m  branch

When you pull from the remote branch, git sees that you have commit d , and the remote branch has commits a , b and c , and you're telling it that you want all those commits in your local branch, so it does this:

local:

     ,--a--b--c--,
--o--o--d--------m
     ^           ^
     m           branch

Where m is a merge commit.

There is no magic that tells git that you no longer need commits a , b and c ; all it knows is that the local and remote branches have different commits.

What you should have done instead, is after squashing all the commits locally, done

git push -f

This would tell git to make the remote branch look like your local branch, throwing away any changes on the remote branch you don't have locally.

You shouldn't do this if anyone else is also using this branch, but it doesn't sound like that would be the case in your workflow.