The reset command is one of git's most commonly used commands, and one of the most dangerous and easily misused.
- git reset [-q] [<commit>] [--] <paths>...
- git reset [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]
- The two usages are listed above, in which <commit> is optional, you can use reference or commit ID, if you omit <commit>, it is equivalent to using the pointer of HEAD as the commit ID.
- The difference between the two usages listed above is that the first usage command includes the path <paths>. In order to avoid the conflict between the path and the reference (or commit ID) with the same name, two consecutive dashes ( minus sign) as a separator.
- The first usage (including the usage of the path <paths>) will not reset the reference, let alone change the workspace, but replace the temporary file (<paths>) with the file (<paths>) under the specified commit state (<commit>). files in the storage area. For example, the command git reset HEAD <paths> is equivalent to canceling the staging area that was changed when the previously executed git add <paths> command was executed.
- The second usage (without the usage with the path <paths>) resets the reference. Depending on the options, the staging area or the working area can be reset.
- Command format: git reset [--soft | --mixed | --hard] [<commit>]
- Using the parameter --hard, such as: git reset --hard <commit> will perform all the actions 1, 2, and 3 in the above figure, namely:
- Replace the reference to point to, the reference points to the new commit ID
- Replace the temporary storage area. After the replacement, the content of the temporary storage area is consistent with the directory tree pointed to by the reference.
- Replace the workspace. After the replacement, the content of the workspace becomes the same as the temporary storage area, and it is also the same as the content of the directory tree pointed to by HEAD
- Using the parameter --soft, such as: git reset --soft <commit> will perform operation 1 in the above figure
- Use the parameter --mixed or not use the parameter (the default is --mixed), such as: git reset <commit> will perform operation 1 and operation 2 in the above figure
- Command: git reset only resets the staging area with the directory tree pointed to by HEAD, and the work area is not affected, which is equivalent to withdrawing the content that was previously updated to the staging area with the git add command from the staging area. The ref is also unchanged, since resetting the ref to HEAD is equivalent to no reset
- Command: git reset HEAD Same as above
- Command: git reset --filename Only the changes of the file filename are withdrawn from the temporary storage area, and other files in the temporary storage area are not changed, which is equivalent to the reverse operation of git add filename
- Command: git reset HEAD filename same as above
- Command: git reset --soft HEAD^ The workspace and staging area are not changed, but the reference is rolled back once, and when you are not satisfied with the latest commit's commit description or committed changes, undo the latest commit in order to re-commit.
- Command: git reset HEAD^ The workspace does not change, the staging area will be rolled back to before the last commit, and the reference will be rolled back once.
- Command: git reset --mixed HEAD^ Same as above
- Command: git reset --hard HEAD^ Completely undo the latest commit, refer back to the previous one, and both the work area and the staging area will return to the state of the last commit, and all the commits since the last time are lost.