Tim Trinidad
Tim Trinidad

Reputation: 162

How can I undo a git rebase that's already been pulled/merged?

I'm in an odd predicament - we had a developer perform a "git pull --rebase" across branches multiple times, and I'm trying to repair the damage. Our graph originally looked like this:

[master]
A--B (origin/master)
___\________________________
[branch]
     \
      C--D--E (origin/branch)

After the faulty merges, our graph now looks something like this:

[master]
A--B---------------H--I (origin/master)
    \             /
     C--D--E--F--G
____________\_______________ 
[branch]     \
              J--K--L (origin/branch)

Commits F and G truly belong on the master, whereas C, D, and E belong on the branch.

What's my best bet for reverting the graph? Commit I has already been pulled onto other branches and local repositories. Is my only option to revert individual commits? The graph above is simplified - there are over 40 commits that were erroneously merged.

I have tried a couple of things, including rebasing F and G onto B, but that created H' and I' and I'm not sure how to deal with the old H and I that were already pulled/merged.

Update

If I did just want to just git revert the specific commits on master and cherry pick them pack onto the branch, how do I "prepend" commits onto the branch? In this case, how do I cherry pick C and D to become parents of J?

Upvotes: 2

Views: 185

Answers (1)

robrich
robrich

Reputation: 13205

+1 for CharlesB's suggestion. Rebase F and G onto B seems like it'll solve the concern. You may also need to rebase H and I to the end too. You'll likely need to push -f (force) to get it into origin, but once origin looks like it should, as users pull, their repositories should also correct themselves.

In Git, the original nodes will always still be there (until a git gc finds them abandoned for some time), but with the master label at the conclusion of the new F, G, H, and I node chain, it will establish the correct lineage.

Upvotes: 1

Related Questions