Git Rollback

Hey there! Hope you’re doing well.

The last blog was a cheat sheet for all the git commands we have covered till now. We saw how to track files, stage or un-stage them, commit the changes, amend commits, branches, and manage merge conflicts.

In this blog, we look at a significant topic in Git, which I personally believe is the whole point of the existence of Git (well, I may also be wrong here).

Every commit made is the latest version of the changes made to the files in that repo. This means the previous commit contains some changes, and the latest commits contain some new changes but are not limited to a feature update, bug fixes, etc.

Say you are working on a particular feature improvement of a website. The most recent commit, which is there, has all the features bug-free. After you finish improving the feature, you made the commit with the updated changes (feature improvement code) and released the website update. After some days, you find out that your code had some error that doesn't work properly on a certain use case, like handling a string of more than 100 characters. But it was working properly in the previous version(before you made the changes).🙆‍♂️ So now what? You will need to identify the bug, rectify, test, and again update the website. This may usually take a lot of time, and you can't bear losses during that time you put towards resolving the error. So Git lets you rollback to the previous commit where everything was working properly so that those instances of the code can be deployed for the website and users don't face any problems. And during that time, you can fix the issue, and when it works properly, you can again deploy the new feature.

There are different ways to rollback in Git. Here, we will use the git revert command.

Revert doesn't mean undoing the changes. I described the scenario above for ease of understanding that you rollback to the previous version. What revert does is create a new commit with the inverse of the changes you made in the latest commit, which means whatever lines were added will be removed, removed lines will be added, and a new commit will be made. So it cancels out the bad commit, and basically, the net effect is just like going back to the previous version before your feature improvement. Here, the history of changes is not modified, but it keeps a record of everything that happens, good commit, bad commit, and then the reverted commit. Revert is useful because it automatically reverses the changes, so you don't need to do it manually.

I'll use my repo from the merge demo.

We made lots of previous commits.

Log of the previous commits

Commits are listed in chronological order.

No Offense, please!

The latest commit is listed first, and as we go down, we see older commits. So you can see the second most recent commit was made in experiment_sort branch, which we merged into the main branch.

To demonstrate the revert, let's create a file with some error💀 and commit it.

As of now, I have these files in my repo.

Create a file called user_greet.py in the folder and write some code.

user_greet.py file

This script will simply print the message. So let's commit it.

Staging file

Commit

All good👌 till here. Right?

Now, say you thought we could make the script more personalized by printing the user’s name with the message instead of just the user. So you update the script accordingly.

Updated script for the personalized message

Now, let's commit it.

Commit the updated code

Now obviously, I created a problem in the code. When we run it, the name variable will not contain anything. And as per the last version, we were at least getting a message, but now we are getting an error.

So now we will revert this version of the code to the previous version (previous commit).

Keep in mind the changes we are making, what lines are being added. It will help you compare with the code after we revert.

Use the following command:

git revert HEAD

Remember, HEAD is like an alias for the latest commit.

When you run the above command, an editor opens.

Notice that you get a default message, the line that's written in yellow and it shows which commit is being reverted. You can and should add more details as to why you are reverting the changes, so it helps other collaborators understand it well.

So now I write the reason I'm reverting the changes.

I wrote the details after the default message, the second line.

Now save the changes and exit the editor. After exiting, the revert will be done and a new commit will be made.

Commit log after revert

See from bottom to top. The last commit was made for the previous blog when we were learning how to resolve a git merge conflict. The third commit was made for this blog when we created the script to greet users. Then we thought to make the greeting more personalized, so we tried making some changes and committed it, which is included in the second commit. But that commit was not good, it had some bugs that needed to be fixed. So for the time being, we wanted to go back to the previous instance of code, so we reverted the changes and then a new commit was made, the first commit in the screenshot. You can also see the messages in the commit log.

The last two entries in the log:

The -p is for seeing the patch created by the commit and -2 is to limit the output to the last 2 commits.

Now observe here carefully. In the second commit (starting with 3db911….), which is the commit before revert, see that one line is removed and two lines are added, which is from when we wanted to optimize the code for a personalized message. This had the error, that's why we reverted, which created the new commit, see the first one in the screenshot. There it shows 2 lines are removed and 1 line is added. The removed lines were the optimized code for a personal message, and the line added by git was the one we originally wrote.

So you see that additions of the last are removed in revert, and removed lines are added back, so its effect is just like moving back to the old commit, while it's actually making inverse of the bad commit.

Till now we saw what we will do if we had to revert the last commit. But what if we have to revert back to a different older commit, like say the 3rd last commit… If we want to revert back to other commits back in time, say we want to remove this user greeting feature entirely, we can use a specific commit id to target that.

A commit id is that 40 characters long string after the word commit, written in yellow.

This commit id is not just jumbled text and numbers. It's a hash calculated using the SHA-1 algorithm.

So we want to rollback to the commit where this feature didn't exist at all. So let's identify that commit from the git log and copy that commit id. That would be the fourth commit from the last in the git log output.

So use the command:

git show 56e5d4af50c66f010e8cf66695c08cd070a90166
or
git show 56e5d4

You can either paste the full commit id or use just a few starting characters of the commit id to let git automatically detect which id we are trying to refer to until there's more id with similar starting characters.

Showing a specific commit from a commit id. This one above is the one in which the greeting feature didn’t exist at all.

To rollback to this commit, use the same command, but now with this commit id instead of HEAD.

git revert 56e5d4
//Your id would be different, so write starting characters of that

So after this similarly, you will get an editor, and then a new commit will be created. Aaaaand, done!🤜🤛

My name is Harsh Seksaria. I like to write about the topics simplifying them as much as possible for you to understand without unnecessary effort. Still, sometimes something may not be very clear. If you find any mistake, error, or you have a suggestion, just mail me. I’ll try to improve it asap.

My email: harsh20.freelance@gmail.com

My LinkedIn: www.linkedin.com/in/harshseksaria