How to merge a development branch into the master and ignore the changes in the master?

Question

following situation:

I made some changes in the development branch ( commit f + g ). Unfortunately, there were some changes in the master branch (commit e + d), which are now obsolete and have to be ignored. So, I am searching for a solution to merge the development branch into the master branch and ignore commits e and d.

So far, I had the following thoughts:

1. Merge and solve the merge conflicts by using the changes from develop: Not possible, since there are also changes in the master that would not appear as merge conflicts
2. Rebase develop branch into the master: No, not really, since the commits d + e would still be there
3. Only working but kind of ugly solution: Create a "revert" branch on the master, revert commits d + e, merge it into master branch and then merge the develop branch.

Do you have a more beautiful idea than though 3?

Answer 1

I agree with the suggestions in Nikola's answer: the more general solution is you should revert the commits on master, then merge in develop. Resetting master back to before those commits also works well here if your team is willing to do that.

There is another option, which is to merge master into develop and ignore the changes brought in by master. But this should only be considered if certain conditions are met:

1. You have so many commits that need to be reverted that it would be cumbersome to revert them all. Note if the commits were brought in under merge commits on master you can simply revert the merge commits, however, you can only do this if you wish to revert all of the commits brought in by that merge.
2. You wish to ignore all of the commits on master that aren't in develop. (There are workarounds if this isn't true, but you do need all of the commits you wish to ignore to be grouped together.)

If you wish to go this route, the commands would be:

git switch develop
git pull --ff-only # Update your copy of develop and if it errors you're out of sync!
git merge origin/master --strategy=ours # ignore everything new on master
# now you can merge develop into master

Note --strategy=ours is sometimes written as -s ours and this merges in commits without their corresponding changes. I would consider this abnormal, and if you do it I suggest using a detailed note in the merge commit message explaining why you did this.

If you have just a few commits that need to be reverted I would recommend just reverting them all, as it's cleaner and easier to historically follow from a reader's perspective.

Answer 2

I say that 3 would be the only acceptable solution, if the commits are already on the remote and other devs have pulled them. You shouldn't change history if someone has already pulled it. If not, you can just reset the master to an early state and force push (ONLY IF nobody else is using it):

git checkout master
git branch master-backup //just in case
git reset --hard @~2 //(if there's only 2 bad commits, or just use the hash)
git merge develop
git push -f