https://www.techtarget.com/searchitoperations/answer/How-to-roll-back-Git-code-to-a-previous-commit
With Git, IT teams can implement version control. Humans make mistakes and sometimes need to roll back to previous versions of content.
Luckily, there are mechanisms in Git that allow programmers to roll back these commits to a known-good version. However, there are potential code implications that can arise when teams execute these commands.
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:
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.
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.
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.
14 Aug 2023