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

Question

Working with git flow. We have a co-worker who is not familiar with Git that accidentally merged develop into master yesterday.

Develop has quite a few features that are launching with our next release, requiring a revert on the merge. This has created a commit which undoes all of the changes. When we merge master back into develop, the revert commit is removing code generated by our features.

What is the best way of going about being able to synchronize develop with master's hotfixes, while preserving the new features?

-- Edit -- Just to clarify, the revert was a revert. I.E. git revert -m 1 <sha>, as the commit had already been pushed to the remote repository.

Since posting this, I've come up with a possible fix, by branching master and reverting the revert, however I'm curious if there are other possibilities that may minimize collision.

Answer 1

Something similar was happening with my team. I actually already have a relatively simple solution, I only found this thread because I was researching ways to prevent this from happening in the first place (still no solution for that).

Here's how I fix it, assuming child branch ("develop") was updated (commit M1) prior to "bad" merge (commit M2) with master:

Problem state

           ... <-- Work after revert that needs merged to develop
            |
            R  <-- Revert Bad Merge
            |
            A  <-- Commits after merge,
            |    /   but before revert 
           ... </    and needs merged to develop
            |
           M2  <-"bad" merge
  ... ____/ |
   | /      |
   M1       |
   | \____  |
  ...     \...
develop   master 

Step 1

# Get latest from both parent and child branches locally

git checkout master
git pull
git checkout develop
git pull


# Merge all code from before revert in master branch to develop
# (not necessary if "bad" merge into master was immediately reverted)

git merge A

State after Step 1:

           ... <-- Work after revert that needs merged to develop
   M3       |
   | \____  R  <-- Revert Bad Merge
   |      \ |
   |        A  <-- Commits after merge,
   |        |    /   but before revert
   |       ... </    and needs merged to develop
   |        |
   |       M2  <-"bad" merge
  ... ____/ |
   | /      |
   M1       |
   | \____  |
  ...     \...
develop   master 

Step 2 - IMPORTANT PART!

# Use "ours" strategy to merge revert commit to develop.
# This doesn't change any files in develop. 
# It simplly tells git that we've already accounted for that change.

git merge R -s ours

State after Step 2

   M4
   | \____  ... <-- Work after revert that needs merged to develop
   M3     \ |
   | \____  R  <-- Revert Bad Merge
   |      \ |
   |        A  <-- Commits after merge,
   |        |    /   but before revert
   |       ... </    and needs merged to develop
   |        |
   |       M2  <-"bad" merge
  ... ____/ |
   | /      |
   M1       |
   | \____  |
  ...     \...
develop   master 

Step 3

# Merge as normal, from the tip of master to develop.
# This should now be an "easy" merge, with only "real" conflicts.
#  (Those that have changed in both branches)
#
# Note: I've had issues using origin master to merge from latest on remote, 
#   so instead I just ensure I've pulled the latest from master locally and 
#   merge from there

git merge master

State after Step 3

   M5
   | \_____
   M4      \
   | \____  ... <-- Work after revert that needs merged to develop
   M3     \ |
   | \____  R  <-- Revert Bad Merge
   |      \ |
   |        A  <-- Commits after merge,
   |        |    /   but before revert
   |       ... </    and needs merged to develop
   |        |
   |       M2  <-"bad" merge
  ... ____/ |
   | /      |
   M1       |
   | \____  |
  ...     \...
develop   master 

Now develop is updated with the latest from master, without having had to resolve repetitive or meaningless merge conflicts. Future merges will behave as normal as well.