恢复合并到主，保持功能分支的变化，不改变历史

Question

I had a feature branch and a master branch. I did some work on the feature, merged into master, pushed the changes, and then deleted the feature branch, both remotely and locally. So far, so good.

After merging, I realized there was a problem with my feature changes. I'd like to undo the merge on master, but still keep the feature changes so I can work on them again. I don't want to rewrite the history of master because other people are working on it too. I think my best bet is to use revert to make new commits that undo the problem?

What I had originally:

A---B---C---D   [master]
     \      
      E----F    [feature]

What I have now:

A---B---C---D---E'---F' [master]

What I want:

A---B---C---D---E'---F'---RE'---RF'        [master]
                                 \
                                  E"---F"  [feature]

RE' reverts E' and RF' reverts F'. Meanwhile E" contains the same content as the original E and F" contains the same content as the original F.

How do I accomplish this?

Answer 1

Again, there are a lot of ways to do this. Here is the command sequence I would most likley use given your desired final state—it ends up being just a hair different than what you drew:

1. git checkout master if needed, then git revert HEAD~2..HEAD to get:

    A--B--C--D--E'--F'--RF'--RE' <-- master (HEAD)

   Note that git revert with a range backs commits out in reverse order.

2. git checkout -b feature :

    A--B--C--D--E'--F'--RF'--RE' <-- master, feature (HEAD)

3. git cherry-pick HEAD~4..HEAD~2 , to copy E--F again:

    A--B--C--D--E'--F'--RF'--RE' <-- master \\ E"--F" <-- feature (HEAD)

If it helps—with longer commit chains, it might—you can add temporary tags to various commits. For instance, if you start with:

A--B--C--D--E'--F'   <-- master

and run:

git tag T1 HEAD~2; git tag T2 HEAD

you get:

        T1     T2
         |      |
         v      v
A--B--C--D--E'--F'   <-- master

So now you can use T1..T2 everywhere to mean "commits E' and F' , so that the revert command becomes:

git revert T1..T2

and the cherry-pick becomes:

git cherry-pick T1..T2

Once you're done, you can delete the two temporary tags:

git tag -d T1 T2

as they were only there to remember the hash IDs of the two specific commits that delimit the range of "interesting" commits. The relative names ( HEAD~2..HEAD or master~2..master ) change their numbering as you add more commits and cause the names to move as well.

Answer 2

I would:

1. Add revert commits to master

git checkout master
git revert HEAD~2..HEAD
git push

2. Re-create the feature branch

git checkout -b feature

3. Cherry-pick feature commits

git cherry-pick HEAD~4..HEAD~2
git push

Answer 3

You could do

# make sure you're working from master
git checkout master

# revert commits E and F
# (but in reverse chronological order is better to avoid unnecessary conflicts)
git revert F E

At this point your tree looks like

A---B---C---D---E---F---F'---E'        [master]

# then create your new branch
git checkout -b feature

# and here you might as well revert the reverts
git revert E' F'

to finally obtain

A---B---C---D---E---F---F'---E'        [master]
                              \
                               E''---F''   [feature]

---

But I'd suggest grouping E and F by using -n during the first revert (then you'll have to commit afterwards), it'll be easier at the next stages to revert the revert, and history will be much more readable. Like this :

git checkout master
git revert -n F E
# (at this point, if you had to resolve conflicts, don't forget to add them)
git commit
git checkout -b feature
git revert E'

and the final tree :

A---B---C---D---E---F---E'        [master]
                         \
                          E''     [feature]

(where in that last schema E' is the revertion of E and F )

Push all this only when you're satisfied with the whole situation.