Article directory
foreword
This article will follow the previous article " [Git] Detailed explanation of git reset command (1) ", continue to combine specific examples and Git underlying commands, and explain the basic use of git reset in detail through graphics and text.
git reset commit – file
git reset [<commit>] [--] <file>
This command will restore the file specified by <file> in the temporary storage area to the status of the commit object specified by <commit>. have to be aware of is:
- If <commit> is not specified, it defaults to the commit object pointed to by HEAD.
- Only the files specified by <file> in the temporary storage area will be affected (git reset [–soft | --mixed [-N] | --hard ] [<commit>] will affect all files in the temporary storage area).
- The –soft and –hard modes cannot be set, otherwise an error will be reported.
- Will not change the pointing of HEAD (git reset [–soft | --mixed [-N] | --hard ] [<commit>] will change the pointing of HEAD).
Let's try out this command by hand.
We create a newfile.txtx file under the working directory (that is, the learngit directory), the content is:
This is a new file.
And, we modify the content of the readme.txt file in the working directory to:
Git is a distributed version control system.
Git is a free software.
Git has a mutable index called stage.
We will add the modified readme.txt file and the newly created newfile.txtx file to the temporary storage area, and submit them to the warehouse together:
The commit history is as follows:
Let's first use the git cat-file command to look at the submission object d4ac459791ee1411bf771cc312092c89de13a1d0 pointed to by the current HEAD:
As can be seen from the figure above, the commit object d4ac459791ee1411bf771cc312092c89de13a1d0 points to a tree object f90c81e6736a257d5aad417426cff9c01d135919. In addition, the parent submission object of the submission object d4ac459791ee1411bf771cc312092c89de13a1d0, that is, the submission object of the last submission is 7b674f020f76a168dbe4bbdec11b1fd137d0b291.
We continue to use the git cat-file command to look at the tree object f90c81e6736a257d5aad417426cff9c01d135919:
As can be seen from the figure above, the tree object f90c81e6736a257d5aad417426cff9c01d135919 points to the data object 67668a2400494229c8f9dd64ec07ee302378a4cb and the data object 85c4f2db496bd7c17f558258f354746c3075c.
The data object 67668a2400494229c8f9dd64ec07ee302378a4cb and the data object 85c4f2db496bd7c17f558258f354744c3075c6a9 correspond to the contents of the newfile.txt and readme.txt files we submitted last time:
Let's use the git ls-files command to look at the status of the current temporary storage area:
As can be seen from the above figure, the data object currently stored or pointed to by the temporary storage area is consistent with HEAD.
Suppose we now want to restore the staging area to the state of our second commit:
Take a look at the commit history:
As can be seen from the figure above, HEAD points to the commit object 68b21576f6d85e1a9eb8121e92a31fd87cdafa65 of the second commit.
Let's check the status of the staging area again:
As can be seen from the above figure, the temporary storage area has returned to the state when we submitted it for the second time.
This is the same as what we demonstrated in [Git] Detailed Explanation of the git reset command (1) .
Before continuing, let's restore the repository to the state of our last commit:
Suppose we now want to restore the readme.txt file in the temporary storage area to the state of our second submission, we can still use the git reset command to specify the submission object and file name, as follows:
Take a look at the commit history:
As can be seen from the figure above, the commit object pointed to by HEAD has not changed!
Let's check the status of the staging area again:
As can be seen from the above figure, the newfile.txt file in the temporary storage area is consistent with the newfile.txt file in the temporary storage area at the time of the last submission, but the readme.txt file in the temporary storage area has fallen back to the temporary storage at the second submission The version of the zone's newfile.txt file.
Open the readme.txtx file in the working directory, the content is still as follows:
Git is a distributed version control system.
Git is a free software.
Git has a mutable index called stage.
From the above attempts, we can conclude that git reset [<commit>] [–] <file> will restore the file specified by <file> in the temporary storage area to the state of the submission object specified by <commit>, while It will not affect other files in the temporary storage area, nor will it change the pointing of HEAD.
What if we want to restore a file in the working directory? Suppose we now want to restore the readme.txt file in the working directory to the state of our second submission:
The result was wrong!
Let's try again with --soft:
The same error was reported!
Summarize
git reset [<commit>] [–] <file>：
- If <commit> is not specified, it defaults to the commit object pointed to by HEAD.
- Only the files specified by <file> in the temporary storage area will be affected (git reset [–soft | --mixed [-N] | --hard ] [<commit>] will affect all files in the temporary storage area).
- The –soft and –hard modes cannot be set, otherwise an error will be reported.
- Will not change the pointing of HEAD (git reset [–soft | --mixed [-N] | --hard ] [<commit>] will change the pointing of HEAD).