Git Reset

Git Reset: The reset command in Git is quite complex and a great tool to undo changes. There are some strict invocations or forms of undoing changes in Git. These invocations act as a management system with the staging area index, head, and the directory we are working on.

As the name suggests, Git reset is quite a familiar command that is generally used to revert the changes. It consists of several layered invocations that influence its core. Those layers are:

* Soft

* Mixed

* Hard

Git is a complex, sophisticated, and tremendously capable tool. The reset command not only undoes the changes but also resets the head state to a specified state. The phenomenon is just like going back in time. It is interesting to note that there are some variations upon which the reset command affects the trees to handle the contents present in your file.

Additionally, Git reset can be used to operate a single-level file or a whole bunch of committed objects. As discussed, the variations play a crucial role in handling the contents in the file. Therefore, these variations give the user a clear vision of what action is necessary and what is not.

Note: The reset command can also be used for reviewing before pushing the files into the main repository from your local system to the remote server and the changes affect individual nodes provided not affecting the current working environment. 

Scope of Git reset

Git uses an index (staging area), HEAD, and working directory for creating and reverting commits. If you have no idea about what is Head, trees, index, then do visit here Git Index and Git Head.

There are three levels of invocations present in the reset module of Git. The modules include index (staging area), HEAD, and the working directory that is used for undoing commits. Let us now look at the methods or commands involved in these three invocations.

Git reset --hard

The --hard reset is the risky, direct, and most used reset option in Git. When invoked, the --hard reset option passes the reference pointers thereby updating the specified commit. The next step involves matching the specified commit with the staging index and the working directory.

If there's a match, the reset command resets them into the previous commit-tree. The effect of this action would make the data lost which was pending in the staging index area and the working directory. To demonstrate this, first of all, make an example repository by creating it with some modifications and then type:

$ git add <index1.txt>  // adds file to your example repository

$ git status                      // check status of your file

$ git log                           // enlist the status of your file

After doing this, type the command:

$ git reset --hard

The --hard reset command will reset and bring the previous commit on display. There will be loss of data from the awaiting work.

Git reset --mixed

This is the default operating mode. The ref pointers are updated. The Staging Index is reset to the state of the specified commit. Any changes that have been undone from the Staging Index are moved to the Working Directory.

The mixed reset option is the default operating mode in Git. In this mode, only the reference pointers are updated by resetting the staging index to a particular commit. This act would solely change the undone from the index area and will move it to the working directory. To perform this reset, like the previous command that we have used to create the file name, we will just add another file by checking the status and adding using the command:

$ git status

And

$ git add <index2.txt>        // this adds the file index.txt

Then we type the mixed reset command. This will move the index2.txt file to the previous file index1.txt.

 $ git reset --mixed
 $ git reset 

As we have discussed, the mixed command is, by default, a reset command.

Git reset --soft

The soft reset mode in Git is essentially used to reset the HEAD. The reference pointers are updated, and the rest stops. It behaves the same as the amend command. Since it is not an author-controlled mode of resetting, developers find it a waste of time.

When the --soft argument is passed, the ref pointers are updated and the reset stops there. The Staging Index and the Working Directory are left untouched. This behavior can be hard to demonstrate. Let's continue with our demo repo and prepare it for a soft reset.

Whenever we reset a file using soft reset mode, the staging index and working directory remain untouched. The behavior is quite difficult to figure out since the resets stop just after referencing the pointers. To demonstrate this, we continue with the above two steps by creating or adding to an existing file, then we type the command:

$ git reset --soft<commit-sha>

This command will switch the HEAD and will display the current head position through the SHA which is the algorithm associated with the head. If we want to go back to the previous commit, we simply take the current head address and type the command.

$ git reset --soft <your current head address>