How to recover from a revert

As a developer there are situations which you may find yourself in where you realise with a sense of impending doom and horror that you’ve made a terrible mistake.

One such situation, is when you accidentally merge your unready feature branch into the master branch. After a few moments of sheer mind-numbing panic you remember that Git has a functionality called a revert. You click the revert button in Gitlab and hey presto! all is good in the world and your code is no longer in master :D.

You carry on working happily, perhaps with a little feeling of smugness that you actually did a revert when most people would shudder in horror.

Then comes the proud moment when you actually do want to submit your work for review and you create a merge request (pull request), only to get the familiar sickening realisation that you have messed up again. You don’t know how, but you know that the revert has done bad things. Because your merge request is not showing any changes!!

You google things a bit, look around then realise that your branch is behind master so you rebase to update your branch and try again. Now things are worse and your merge request is showing a shocking number of conflicts which never should have existed!

This is when you truly panic. I don’t know about you, but when this happened to me the first time. I. Flailed. My temperature and blood pressure rocketed and I began to literally feel hot under the collar. I could hear the blood rushing through my ears and my vision was narrowing. I started to resolve the conflicts painstakingly, only to mess up and start again. Repeatedly.

Eventually, after much googling, asking fellow colleagues, and drinking copious amounts of coffee I was introduced to the concept of reverting the revert!

Sounds like a contradiction in itself! How do we do this though?

Step 1 — Branch off your feature branch and pull in the latest code from master

Pull the latest code from master. This should contain the revert commit, copy the commit hash and keep it in a safe place :). Alternatively, if you used a tool such as gitlab you can take the revert commit from there.

git checkout master && git pull origin/master

Branch off the feature branch which got reverted and update it with the changes from master.

git checkout feature/original-feature-branch
git checkout -b feature/new-branch-to-revert-revert
git merge master

step 2 — Revert the revert

git revert -m 1 [commit hash of the revert]

Step 3— push the code up and create a new merge request

And that’s it! once you push this code up to origin and create a new merge request the revert of the revert will neutralise the effect of the revert which is in master allowing you to put your code back in.

Now comes the questions; what about the conflicts? why did they happen in the first place?

The answer to that lies in the definition of the revert taken from here:

git revert is used to record some new commits to reverse the effect of some earlier commits

So, a revert doesn’t undo history, A revert is as though someone took some code and deleted it then committed that change under a new commit hash.

Well wait a minute! doesn’t rebasing also create new commits?

Now, we all know that if two people change the same line of code and submit them, they will face conflicts. Even if they both added the exact same thing. Git doesn’t care about the type of change, it only cares about the commits and if the commits are different but target the same place; a conflict will happen. So when you do a revert then try to merge in your rebased code again it will be as if two people are changing the exact same areas of code. And that is how your conflict happens.

I hope this article helps anyone looking for a solution to a botched revert. If you like this article, please do give some claps, they encourage me to make more content :). I’m also happy to receive any questions or comments.