Revert the Revert and Avoid Conflicts

Let me tell you my story about git, conflicts and reverts.

On a project, I start a feature on a branch, open a pull request towards master branch and merge it by mistake before finishing my code.
No git story would be complete without drawings.

Oops!

What is the clean way to fix my mistake?

My first idea is to quickly push --force to master branch to cancel the merge when nobody is looking.
I read on the Internet that this is a bad idea on a shared branch.
Therefore, I decide to do it the “clean way”, which in my case is revert.

I can revert manually on the command-line, or thanks to GitHub directly from the merged pull-request!

My git history now looks like this:

Now is the time to deploy my code.

I can’t merge my feature, what’s going on?

I’ve added my missing commit, I reopen a pull request and see this on GitHub:

How does a merge commit work?
A merge commit takes the diff between the common ancestor and the first parent commit and the diff between the common ancestor and the second parent commit and applies them together.

Let’s look at my git history:

Now suppose my feature introduced a new file script.sh, and that I modified it in my feature branch after the revert.

Let’s see what this means:

That’s great!
I understand that the revert commit is the culprit here.
But how do I get back on my feet and merge my feature?

Solution: revert the revert!

I want to avoid the revert commit in my merge, therefore I rebase my feature branch on master branch so that the merge commit common ancestor is after the revert commit.

I can’t apply my feature commit on master branch because script.sh does not exist.
I need a commit before that reinstates script.sh and that is not already merged into master branch.

That’s where the magic occurs, I revert the revert commit, and then cherry-pick my new commit.
Let’s see this in action:

It’s working, at last!

Epilogue

This solution requires a good visualization of the situation to understand and implement it.
Always draw when you have a problem with git.

The best way to avoid all this work is to avoid the mistake in the first place:
be careful when merging your pull requests.

I rejected the push force method because it is dangerous, but my solution is quite thorny!
There are situations where push force is indeed a good choice, even on a shared branch.
Be sure to warn your collaborators and explain to them the necessary steps to recover from it if needed.