How to roll back Git code to a previous commit

What is git reset?

Every time an IT admin commits a Git deployment, that latest commit becomes the head, or tip, of the code tree -- in other words, the current version. The Git commit process provides a point-in-time snapshot (PIT snapshot) of the version-controlled files at the time of every change.

An administrator can roll back the code repository to a previous commit -- that point-in-time copy -- in several ways, depending on the end goal. One approach is the git reset command.

Before using this command, teams must understand what git reset does. Outcomes can vary between command uses and with which switches. Use the command with caution. There are two modes for git reset:

• Git reset soft. This mode resets the code tree's head to the designated former commit instance. All the files between that PIT snapshot and now are set to staged -- ready to commit but not yet committed. This is the default mode.
• Git reset hard. Use this mode with extreme caution because the changes can't be reverted. This command will reset everything, move the head back to the indicated commit version and remove all changes added to the code tree after that specific version number. In effect, the git reset command instantiates a "hard deletion" of all changes from now -- or point in time of code reversion -- to the designated former code commit. It resets the code tree to the version in question and deletes unstaged files.

Git reset example

First, decide how far back to go into the version history. To view the previous commits, use the git log --oneline command. This command provides the commit details.

Once the team chooses a code version they want to revert their tree to, use the commit ID to execute the command. In the following example, a soft reset is used since --hard is not specified. The code 3a96a8e represents the commit ID, gained from the git log output in Figure 1.

Alternatively, there is a shorthand method to roll back the commit without knowing the necessary commit ID. Admins can reset code versions relative to where the current head is using the code in Figure 3.

In the example, ~1 refers to the number of commits backward that the code tree will revert to. The image below illustrates the results of adding several commits and then resetting back one version.

Git revert example

Admins can also use git revert. This command undoes the effects of a bad or incorrect commit by creating a commit that does the opposite of the commit in question. By reverting the commit in this manner, the history stays intact.

Teams can use git log --oneline again to see the current commit IDs.

Then they can revert to a specific commit with similar syntax as the reset command. However, the difference here is that the command specifies the commit ID that needs to be undone rather than the commit ID that the team wants to reset to.

In Figure 5 there's an additional parameter: --no-edit. This prevents Git from opening the default editor to specify a custom commit message.

Figure 6 displays how the git history will look.

In this scenario, all changes made in the second commit were reverted with an additional commit that does the opposite.

Git reset vs. git revert

In choosing between git reset and git revert, it's important to understand exactly what each one does. Git reset will delete commits from the history, so if admins are working locally and haven't pushed any commits, this will likely be the better option.

But if the team has pushed the commits, consider git revert instead. That way, anyone who has pulled the bad commit can also pull the revert commits as well.

Before making any changes, test these actions in a local copy of a repository. That way, if admins make any mistakes, they can fall back to executing a git pull.

Editor's Note: This article was originally written by Stuart Burns in 2021. Anthony Howell revised and expanded upon it in 2023.