The straightforward way to undo a merge
A better way to undo a merge is to use git reset. If you don't care to save any of the results of the merge, and assuming a clean working copy, you can just do the following with branch A checked out to your working copy.
git reset --hard D
If the workspace is not clean, or you want to save the results of the merge for some reason, you can do this:
git reset --mixed D # actually, you don't have to specify 'mixed', as this is the default
Both commands will leave your graph like this:
A--B---C--------D---> (Branch A)
\
\---E--F--G--> (Branch B)
However, the second command will leave changes in your working copy. See the git help reset manpage for more info. Here are the key parts:
git reset [<mode>] [<commit>]
This form resets the current branch head to <commit> and possibly updates the index (resetting it to the tree of <commit>) and
the working tree depending on <mode>. If <mode> is omitted, defaults to "--mixed". The <mode> must be one of the following:
--mixed
Resets the index but not the working tree (i.e., the changed files are preserved but not marked for commit) and reports what
has not been updated. This is the default action.
--hard
Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded.
Doing it this way makes future merges perfectly normal because there is no history of reversion. As far as git is concerned, the next time you do a merge will be the first time and your life will carry on.
As a side note, the original merge commit, H, will still actually remain in your repository - however: if you have gc.auto set, then some commands will cause a gc, which prunes unreachable commits from your repository, which would include H. If you for some reason want to hang on to the merge commit, you need to create another branch to hold a reference to it or turn off gc.auto and write down the first 7-8 characters of its commit id so you can find it again.
Oh crap, I did this on a public branch
Official guidance would have you avoid rewriting history on a published branch at all costs. I think the right way to think about it is to evaluate your costs. How many downstream clones do you have? Do any of them actually contribute work, or are they just mirrors? Is it really going to bother you that much to possibly have duplicate commits in your log history (only one time, hopefully)?
The nut of the question:
Is there any proper solution for undoing a merge (to a public
repository), while still maintaining the ability to merge that branch
back in in the future?
doesn't have a nice and tidy answer. One way is to revert the merge as suggested, leaving you with commit I:
A--B---C--------D--H--I--> (Branch A)
\ /
\---E--F--G-/--> (Branch B)
To make this more obvious, let's relabel the revert as H'. When you're ready to merge again, first enable rerere (rerere.enabled) and then revert the revert:
A--B---C--------D--H--H'--J--K--H''--O-?> (Branch A)
\ / /
\---E--F--G-/---L---M----N----/ (Branch B)
If there are conflicts, then work through them the best you can and let rerere record the results (see the man page for details and how to do it right).
Junio Hamano and Linus Torvalds wrote a thorough explanation of this "revert-the-revert" scenario, and since writing this answer, I think "revert-the-revert" is the right answer for your scenario.
