How to Undo Git Reset
In this tutorial, you will learn about the short and more detailed methods of undoing git reset. Also, get familiar with the concept of the three trees.
Everyone makes a mistake and one of the most useful features of any version control system is the system of undoing changes. Here, you will get a simple and straightforward way of undoing the git reset.
Suppose that you have run <kbd class="highlighted">git reset HEAD~1</kbd> by mistake, which has deleted the latest commit from your local branch and, now, you want to restore that commit. Below, we will demonstrate how to do it.
Undoing git reset with git log
Viewing reference updates
Git keeps a log of all reference updates (e.g., checkout, reset, commit, merge). Run the git reflog command to view them:
git reflog of all reference updates
git reflogThe output may be something like this:
49ab751 HEAD@{0}: reset: moving to HEAD~1
b53c078 HEAD@{1}: Change the length ...Undoing git reset
Run the following command to undo your mistake and go back at the commit before resetting:
git reset
git reset HEAD@{1}Undoing git reset with the --hard option
If the remote-tracking branch corresponding to your branch is synchronized with your current branch before resetting, you can call the command below to undo the git reset: (suppose, the name of remote is origin, which is by default):
git reset to the remote-tracking branch
git reset --hard origin/`<branch-name>`The git reset Command
The <kbd class="highlighted">git reset</kbd> command is used for undoing changes. It is somewhat similar to git checkout as they both operate on <kbd class="highlighted">HEAD</kbd>. The <kbd class="highlighted">git checkout</kbd> command works exclusively on the <kbd class="highlighted">HEAD</kbd> reference pointer, while <kbd class="highlighted">git reset</kbd> moves the HEAD and branch pointers to the specified commit. By default, it uses the --mixed flag, which updates the staging area to match the target commit but leaves the working directory unchanged.
Take into account that you should not use <kbd class="highlighted">git reset</kbd> <commit> when there are snapshots after the <commit>, which are pushed 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
<kbd class="highlighted">HEAD</kbd> points to your branches, like the master branch by default. <kbd class="highlighted">HEAD</kbd> 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 <kbd class="highlighted">HEAD</kbd> is pointing at, at any specified moment.
Each of these trees does a different job, but they are equally crucial for Git operation.