Reset is probably one of the least understood git commands with the addition of having a bad reputation for being dangerous. There is a valid reason for both of these claims: yes, the reset command is a bit harder to understand and in some cases, it can be dangerous. But, it is not all that hard. So in this post, I will give my best to present you with a clear and distilled tutorial to the reset command. To make it short and not too overwhelming I have abstracted the non-essential details and simplified some things, but if you want to know more on git’s internal workings you can also check my Understanding Git series for more details of some stuff presented here. Git Threes Before we dive into the command we need to take a look at what is called the trees of git: Working Directory, Staging Area and the Repository. reset You can think of them as three areas where changes can reside from git’s point of view: Working Directory — your project files on your filesystem Staging Area — a preview of the next commit Repository — datastore where git keeps all (past) commits. The command operates on these threes/areas, but first, let’s take a look how do and commands (that we use daily) affect these areas. reset add commit Say we have a web app and we do some refactoring on our file. Changes that we make are reflected in the Working Directory: index.php We can confirm this by running : git status Changes not staged for commit:(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory) modified: index.php Now we move those changes to the Staging Area by using the command: add Running the command will tell us: status Changes to be committed:(use "git reset HEAD <file>..." to unstage) modified: index.php Because the command sees that we have the same version of file both in Working Directory and in the Staging Area, but not in Repository. status index.php To add it there, we use the command: commit And now the Working Directory, Staging Area and Repository all contain the same version of , and running will tell us that there is: index.php git status nothing to commit, working tree clean So, the way the command works is that it compares file versions in Working Directory, Staging Area and Repository and if there are different than there are files to be staged/committed. status Let’s say we do some more refactoring on the file and do the whole add/commit cycle again. index.php Now our Working Directory, Staging Area and the Repository will all contain the new second version of our file. index.php But what about the first version? If you remember, we did say that the Repository keeps all previous commits, so the first version of is still there: index.php To keep track which version of the file is the current one, Repository has a special pointer called that points to the current version (and the command only looks at the current version that is pointing to when comparing it to the Staging Area’s version). index.php HEAD status HEAD Now that we have that covered we can finally go to our command and see how it works by manipulating the content of these git areas (trees). reset reset — soft This first mode of command will only do one thing: reset move the pointer HEAD In our case, we will move it to the previous commit (the first version of ) by runing: index.php git reset --soft HEAD~1 The trees of git now look like this: And when we run we see a familiar message: git status Changes to be committed:(use "git reset HEAD <file>..." to unstage) modified: index.php So, running has basically undone our last commit, but the changes contained in that commit are not lost — they are in our Staging Area and Working Directory. git reset — soft HEAD~1 reset — mixed The second mode of command will do two things: reset move the pointer HEAD update the Staging Area (with the content that the is pointing to) HEAD So, the first step is the same as with the mode. The second step takes whatever the points to ( in this case, it is version one of the file) and puts it into the Staging Area. --soft HEAD index.php So, after running our areas look like this: git reset --mixed HEAD~1 And running now again gives us a familiar message: git status Changes not staged for commit:(use "git add <file>..." to update what will be committed)(use "git checkout -- <file>..." to discard changes in working directory) modified: index.php So, running has undone our last commit, but this time the changes from that commit are (only) in our Working Directory. git reset — mixed HEAD~1 reset — hard And now for the notorious hard mode. Running will do three things: reset — hard move the pointer HEAD update the Staging Area (with the content that the is pointing to) HEAD update the Working Directory to match the Staging Area So, the first two steps are the same as with The third makes the Working Directory look like the Staging Area (that was already filled with what is pointing to). --mixed. HEAD So, after running our areas look like this: git reset --hard HEAD~1 And running git status gives us: nothing to commit, working tree clean So, running has undone our last commit and the changes contained in that commit are neither in our Working Directory or the Staging Area. But they are not completely lost. Git doesn’t delete commits from Repository (actually, it does sometimes, but very rarely), so this means our commit with the second version is still in the Repository, it is just a bit hard to find (you can track it by looking at something called ). git reset — hard HEAD~1 reflog So, what is then with this reputation of reset being ? Well, there is one case where some changes could be permanently lost. Consider a scenario where after the second commit you make some more changes to your file, but you don’t stage and commit them: dangerous index.php And now you run : git reset --hard HEAD~1 Since the overwrites the content of your Working Directory to match the Staging Area (that is already made to match ) and you never staged and committed your changes so there is no commit with those changes in the repository, all those changes will now be lost in time… Like tears in the rain. reset --hard HEAD The danger of hard reset lies in the fact that it is not Working Directory safe — meaning it won’t give you any warning if you have file changes in your Working Directory that will be overwritten (and lost) if you run it. So be (extra) careful with a hard reset. And there you have it — the reset command. I hope I did a good job explaining it and that you’ll agree it is not that hard after all. And, yes it can be dangerous but only if used with option. --hard As said in the beginning if you would like to know more on the inner workings of git, you can check my series, and if you want a more in-depth explanation on the reset command you can check the chapter from Scot Cachon’s git pro book. Understanding Git git reset demystified Appendix: In the examples, we used we used as an argument for the command. As you probably already know every commit in git has a unique identifier called a , and we can use it as an argument for the reset command too to reset to a specific commit HEAD~1 reset checksum To make examples simpler we only had one file that we edited and committed, in reality, we often commit multiple files, so a specific commit holds different versions of multiple files. The special pointer usually doesn’t point directly to a commit (as shown in examples for simplicity) but to a branch pointer that then points to a specific commit HEAD
