Note on `git reset`

DONG Yuxuan @ Jan 26, 2020 Asia/Shanghai

Git is complicated to me. Write down for recalling.

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.