How to Undo Git Reset

Everyone makes a mistake and one of the most useful features of any version control system is the system of undoing changes. In this tutorial, we will show two methods of undoing git reset.

Here, we suggest a shortest method to undo git reset:

git reset 'HEAD@{1}'

Git keeps a log of all reference updates (e.g., checkout, reset, commit, merge). Run the git reflog command to view it:

git reflog

The lost commit is in the list. Somewhere in this list is the commit that you lost. Assume you typed git reset HEAD~ and need to undo it:

git reflog
5d8cd24 HEAD@{0}: HEAD~: updating HEAD
c56237e HEAD@{1}: checkout: moving from c56237e1fc28463f1c1f0cc4486a1447a6282b1c
[...]

The first line indicates that the current position is 5d8cd24; it was obtained by resetting to HEAD~. The second line indicates that the state before the reset is d27924e. It was obtained by checking out a particular commit. For undoing the reset, run git reset HEAD@{1} or git reset c56237e.

If you have run other commands since then that update HEAD, then you need to search through the reflog as the desired commit won't be at the top of the list.

The final step is to view the reflog for the specific branch (the master branch) you want to un-reset:

git reflog show master
c18374b master@{0}: merge origin/master: Fast-forward
15a1bf6 master@{1}: merge origin/master: Fast-forward
[...]

The git reset Command

The git reset command is used for undoing changes. It is somewhat similar to git checkout as they both operate on HEAD. The git checkout command works exclusively on the HEAD reference pointer, while git reset passes the HEAD reference pointer and the current branch reference pointer.

Take into account that you should not use git reset <commit> when there are snapshots after the <commit>, which are moved to a public repository. When you publish a commit, remember that other team members also rely on it. Removing commits that are being developed by other members of the team will cause lots of issues. It is best to remove local changes.

The Three Trees

Git uses three different versions of files for the workflow of adding and retrieving commits. These systems include:

  • HEAD (the commit history)
  • the staging area
  • the working directory

HEAD points to your branches, like the master branch by default. HEAD is a reference that changes and points to the currently checked out branch, and through that branch, the last commit on it.

The staging area or index is where commits are prepared. The staging area compares the files in the working tree to the files in the repository. When making changes in the working tree, the staging area marks the file as changed before it is committed.

The working tree or working directory is a version of a particular snapshot or a particular commit of a checked-out project. The working directory represents the files on your computer's file system available to the code editor to apply changes. It is the version of the Git history that HEAD is pointing at, at any specified moment.

Each of these trees does a different job, but they are equally crucial for Git operation.


Do you find this helpful?

Related articles