Pipetus
Pipetus

Reputation: 1136

git - how to revert a wrong rebase after a merge

I have the following simple branch model:

A--B--C  <- master       

D--E--F  <- production, origin/production

At a point, I merged back to master:

A--B--C--M  <- master
         /
D--E--F-/   <- production

And then tried a rebase of another branch against master (using --onto) but stood in the wrong place, so the history turned into:

A--B--C--M  <- master,production    
         /
D--E--F-/   <- origin/production

So, right now, I have master and production pointing to the same commit, which should be only the one for master.

How do I point production back to origin/production?

Upvotes: 0

Views: 110

Answers (1)

torek
torek

Reputation: 488193

I find this is a lot clearer if you make sure your labels are on the right side, pointing to the branch tip commits, since this is how branch names actually work in Git (they point to one commit, which we call the tip of the branch):

A--B--C--M   <-- master
        /
 D--E--F     <-- production, origin/production

When you did the thing you did, you copied no commits (fortunately) and simply moved the label production to point to commit M:

A--B--C--M   <-- master, production
        /
 D--E--F     <-- origin/production

So all you need to do now is put the label back, so that the name production means "commit F". To do that, you can use the commands Whymarrh gave in a comment:

git checkout production && git reset --hard origin/production

The git reset --hard tells Git to:

  • reset the current branch (--soft, --mixed, and --hard all do this) to point to the target commit F;
  • reset the index (--mixed and --hard both do this) to have as its contents, the contents of the target commit F; and
  • reset the work-tree (only --hard does this) to have as its contents, the contents of the target commit F.

Because the first step resets the current branch pointer, we need the git checkout to select production as the current branch (unless it's already current, of course).

Resetting the index and work-tree are desired side effects at this point, since we don't plan to carry any of the index or work-tree contents extracted from commit M back into a new commit after F.

Upvotes: 3

Related Questions