You can use git revert
to revert the merge. Just be aware that when you do that, you make a future "re-merge" more difficult. Read that message you linked closely—it says a lot about how to make the future "re-merge" work—but be aware that it's talking about merging develop
into master
, and you said you did the opposite, merged master
into develop
:
A -- B -- C -- D -- E <-- master
\ \
F - G - H - M <-- develop
In this case (having merged master
into develop
instead of the other way around) you can choose a number of different options, all with advantages and drawbacks...
The easiest method, which I prefer if it's an option
(0) Do nothing. If merging in C
and D
doesn't break the develop
branch, just leave it that way. Later, someone will git checkout master
and git merge --no-ff develop
and get this (let's say one more commit I
got added to develop
first):
A -- B -- C -- D -- E -- M2 <-- master
\ \ /
F - G - H - M - I <-- develop
Here merge
finds what's been done in develop
since it split off from master
, which was at B
. So it puts in F
, G
, and H
, skips any parts of M
that came off master
(probably all of it), and finally puts in I
and makes merge-commit M2
(because of commit E
; but if E
were not there, it would be because I used --no-ff
too).
Some easy methods with obvious drawbacks
(1) Just "rewrite history": erase commit M
from branch develop
. Alert everyone else who uses the branch that this is about to happen: that commit M
is going away and they should take whatever measures they must, to handle this.
(2) Stop using the old name develop
, make a new branch name develop1
or whatever:
A -- B -- C -- D -- E <-- master
| \
| M <-- develop
\ /
F - G - H <-- develop1
This is the same as option (1) except that the commit M
is still there, along with the branch label on it, and you have a new/different branch label pointing to commit H
. You still need to alert everyone, but it might make their jobs easier. You can delete develop
later, when everyone is good with that.
The revert and its drawbacks
(3) Revert the merge. As in the linked article, let's use W
to represent the new revert commit:
A -- B -- C -- D -- E <-- master
\ \
F - G - H - M - W <-- develop
What's in W
? Whatever it takes to "erase the effect" of the merge. In this case, that means, changes that un-do whatever was done in C
and D
. So far so good, develop
has just the changes from F
, G
, and H
, again. The problem occurs later, if/when someone does:
git checkout master
git merge develop
The second command goes rooting around to find where master
and develop
were split, i.e., commit B
, so it picks up all the changes since then. Which at this point include those in W
, which will un-do C
and D
, not at all what you wanted. It can be fixed-up afterward, but whoever does the merge has to know about this "delete C
and D
" time-bomb waiting for them.
Note that this is the same merge as in the "do nothing" option (0). The issue here is the contents of W
. In case (0), you want the contents of commit I
, but here you don't want the contents of W
.
One more option
This is arguably the worst option of all, given what's shown above, but I'll list it anyway:
(4) make an all-new branch with copies of the commits you want to keep, and name it develop
. (Or name it something else, but then we're back to the develop1
-like situation above, and you should probably just use that one.) Whether you keep the old-develop
branch, or just abandon it (by not labeling it), is up to you, but I will draw it in:
F' - G' - H' <-- develop
/
A -- B -- C -- D -- E <-- master
\ \
F - G - H - M <-- old-develop
This is described in the link you included. It's only really useful in more complex cases.