Git ~ Reset - rohit120582sharma/Documentation GitHub Wiki

Use git reset to return the entire working tree to the last committed state. This will discard commits in a private branch or throw away uncommitted changes!

At a surface level, git reset is similar in behaviour to git checkout. Where git checkout solely operates on the HEAD ref pointer, git reset will move the HEAD ref pointer and the current branch ref pointer.

This operates on "The Three Trees of Git". These trees are the Commit History (HEAD), the Staging Index, and the Working Directory. The options --soft, --mixed , and --hard can be passed to git reset .

Git reset will never delete a commit, however, commits can become 'orphaned' which means there is no direct path from a ref to access them.

You should never use git reset when any snapshots after have been pushed to a public repository. After publishing a commit, you have to assume that other developers are reliant upon it.

reset — soft

This first mode of reset command will only do one thing:

move the HEAD pointer

git reset --soft HEAD~1

So, running this command 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.

And when we run git status we see a familiar message:

Changes to be committed:
	(use "git reset HEAD <file>..." to unstage)
modified:   index.php

reset — mix

The second mode of reset command will do two things:

move the HEAD pointer
update the Staging Area (with the content that the HEAD is pointing to)

git reset --mixed HEAD~1

So, running this command has undone our last commit, but this time the changes from that commit are (only) in our Working Directory.

And running git status now again gives us a familiar message:

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

reset — hard

The third mode of reset command will do two things:

move the HEAD pointer
update the Staging Area (with the content that the HEAD is pointing to)
update the Working Directory to match the Staging Area

git reset --hard HEAD~1

So, running this command 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 **reflog**).