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 tha
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.