Avoid the effects of a revert commit in another Git branch while merging

Option 1: Hard reset and force push

If it's possible to do a non-fast-forward forced-update to your master branch in your upstream repository, then instead of reverting the merge of develop into master, you could simply do a hard reset of master:

# On master branch, do a hard reset back to the commit before the merge git reset --hard <commit of master before the merge> # Force push to upstream ONLY IF IT'S OK WITH OTHER DEVELOPERS git push <remote> master --force 

A possible disadvantage to doing a hard-reset and force-push is that if other developers have already based work off of the merge commit (i.e. have made commits on top of it), then they'll need to redo that same work on top of the reset head of master. This may or may not be a difficult/costly task for them.

Option 2: Revert the revert

I tested this out with a quick test repo. I have to stress that it might work, I'm not 100% confident that there aren't any cases that I didn't consider. So be sure to test it out locally with a backup clone of your repo first. If you choose to use this in your actual repo, please do so at your own risk.

Also, this may not be the easiest/simplest solution. Its advantage over the hard-reset option, however, is that it doesn't force developers to have to redo work on top of a reset master branch.

Ok, with all of that out of the way, one thing you could try doing is merging master into develop, then revert the revert of the merge from develop into master, then merge develop into master when you're ready. In commands:

# Coworker accidentally merges develop into master before it's ready git merge --no-ff develop # You revert the merge in the master branch (this creates commit "ABCDEFG" git revert -m 1 <sha of merge commit> # You want to merge fixes from master into develop git checkout develop git merge --no-ff master # But now all that work in develop is reverted, so revert the revert "ABCDEFG" git revert ABCDEFG # When you're ready to merge develop into master... git checkout master git merge --no-ff develop 

Here's a sequence of commands I used to test this out in a test repo:

mkdir practice cd practice/ git init touch readme.txt git add practice.txt git commit -m "Add practice.txt" git checkout -b develop touch feature1.txt git add feature1.txt git commit -m "Add feature 1" touch feature2.txt git add feature2.txt git commit -m "Add feature 2" git checkout master touch hotfix1.txt git add hotfix1.txt git commit -m "Fix issue 1" git merge --no-ff develop # Creates commit "ABCDEFG" that reverts the merge git revert -m 1 head git checkout develop git merge --no-ff master git revert ABCDEFG git checkout master git merge --no-ff develop 

You can read more about the "Reverting Revert" technique at the official Linux Kernel Git documentation for git revert:

-m parent-number

--mainline parent-number

Usually you cannot revert a merge because you do not know which side of the merge should be considered the mainline. This option specifies the parent number (starting from 1) of the mainline and allows revert to reverse the change relative to the specified parent.

Reverting a merge commit declares that you will never want the tree changes brought in by the merge. As a result, later merges will only bring in tree changes introduced by commits that are not ancestors of the previously reverted merge. This may or may not be what you want.

See the revert-a-faulty-merge How-To for more details.

The link to How to revert a faulty merge is highly recommended if you fully want to understand how this technique works, it's not difficult to understand and it actually kind of interesting and fascinating.