Git serves a few purposes in your project. One of those purposes is a safety net. It allows you to make experimental changes to your code, and not have to worry about paying much attention to the state it was in when you changed it. That state is already available through one of your commits if you need it. There are three primary ways I turn back the clock in Git: reset; checkout; and revert. Let’s take a look at the reset command.
This command is very powerful. It is one of the only commands that can make a change that cannot be recovered. Given this, you must take great care when you make the decision to use it on your commits.
Resetting the index
The first, and most common use of this command is to reset the index, or staging area. Once you have made changes to a file, and used the add command to place it in the index, it will be placed in the next commit. There will undoubtedly be situations where you add a file to the index, and later decide you do not wish for its changes to be included in the next commit. Enter the reset command. All you have to do is supply the reset command with the filename, and your file will be unstaged. The command takes the form git reset -- ExampleFile.txt.
Changing the mode
There are three modes you may run the reset with. Each mode builds upon the last adding functionality. The three modes are –soft, –mixed(default), and –hard. Here is where care must be taken because the commits in between your head, and the commit you’re resetting to will be lost. Depending on the mode, different changes are abandoned starting with only commits, and ending with all changes.
–soft
The most basic mode is –soft. Running the command in this form: git reset --soft [commit] will take your head, which is your primary pointer, and move it to point at a different commit. Any changes made to any file between the commit you supplied to the reset command, and the commit your head was pointing at will be staged. Any changes staged remain so, and the same goes for changes not staged. This command is useful when you would like to keep all changes, and only change the commit history. There are, admittedly, other, and better ways to accomplish this, so use of this form is rare.
–mixed
This is the default mode, and adds onto the functionality provided by the previous mode. Running the command in this form git reset [commit] will also reset your staging area to match the commit you are resetting to. Using this command to reset to a commit other than HEAD (which performs an unstage) is pretty rare as, again there are better ways to accomplish the goal most likely being attempted.
–hard
Here we go… In this mode, reset is fully realized. Running the command in this form: git reset --hard [commit] adds the functionality of updating the files to match the commit effectively abandoning all changes. If the changes were never committed, then the changes are lost. Use care here.
Wrap Up
Outside of unstaging changes, use of this command is rare as there are better ways to do the functionality provided by this command, and very rarely do you make changes that should be completely abandoned. I am of the camp where you should have familiarity with all commands so when you come up to a situation, you can make better decisions about how to handle it because you know the options.
