# Note on git reset

DONG Yuxuan @ Jan 26, 2020

There’re two forms of git reset usage.

## The First Form

git reset [options] [tree-ish] [--] [paths]


The first form overrides the content of the stage for all paths with the content of all paths at tree-ish. For example, if we want to discard changes in the stage, we could run the following.

git reset HEAD -- .


This will reset the state of the stage to the state at HEAD. That means we discard all changes that added but not committed.

If we want to make README.txt go back to the state at HEAD^. Run the following.

git reset HEAD^ -- README.txt


Now, README.txt at HEAD^ is in the stage but not in the working tree. We could checkout it to the working tree.

git checkout -- README.txt


After checkout, you could view the file and it should has the same content with it has at HEAD^.

We could commit the current stage to the repository by git commit -m 'message'. After this, the new commit that makes README.txt go to an elder version is made.

## The Second Form

git reset [options] <commit>


This form will move the HEAD to commit. For example, we could run git reset --hard HEAD^ to make ‘HEAD’, the stage, the working tree all back to the last commit.

Common options are the following.

• --soft

Don’t touch the stage or the working tree

• --mixed

The deafult value

Reset the stage but not the working tree

• --hard

Reset both the stage and the working tree