DONG Yuxuan @ Jan 26, 2020
There’re two forms of
git reset usage.
git reset [options] [tree-ish] [--] [paths]
The first form overrides the content of the stage for all
paths with the content of all
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
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
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.
git reset [options] <commit>
This form will move the
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.
Don’t touch the stage or the working tree
The deafult value
Reset the stage but not the working tree
Reset both the stage and the working tree