Manage modifications
1. cd testgit ---> git init ---> create a doc1.txt file and write the content ---> git add doc1.txt ---> modify doc1.txt ---> git status to view the workspace Status, showing file modification, which is as expected
2. After committing again, git status checks the status.
3. Hey, why is the workspace not "clean"? Why is it still modified? Isn't it all commits to the master branch? It turned out that after I modified the file for the second time, there was no git add doc1.txt, so I did not submit the second modified file to the staging area (stage), and commit was only responsible for submitting the changes in the staging area to the branch. After submitting, use the git diff HEAD -- doc1.txt command to view the difference between the latest version in the workspace and the repository ( to be precise, the difference between the latest version on the branch in the workspace and the repository ):
4. Well, if you know the reason, it will be easy to handle, just add it again. Well, the workspace is back to "clean". Why does my screenshot show a qq?
Undo changes
1. Or operate with the doc1.txt file. Pretend you are practicing English and accidentally type Chinese. So, you want to delete these Chinese. Of course, you can just delete it manually (em, so you don't have to read it!).
So, I used the almighty git status and found the prompt git checkout --<file> , well, it is him, which can discard the user's modifications in the workspace .
There are two cases here
<1> If the file modified by the user has not been added to the stage, it will be restored to the same state as the repository
<2> If the user modifies the file after adding, then it will return to the state when the user just submitted it to the stage
In short, the above two cases are to restore to the state of the last git commit or git add
2. Some people will think, if I modify the file and add it to the stage, can it be restored through git checkout? em? Who knows, then use git status to see it.
Judging from the returned results, it is no longer possible to use git checkout <file>. Of course, there is still a way to recover. You can first use the command git reset HEAD file to undo the modification of the temporary storage area and put it back into the working area.
Ok, so you can restore it through checkout
Finally, your workspace is clean again
Delete Files
1. For git, deletion is also a modification. If you create a new file and delete it, you can just rm it directly. This is because: if you delete a file, it means that your workspace has not changed, and this file is not recorded in your repository, so git status cannot detect the status.
However, if the deleted file is recorded in the git repository, then you can delete it directly by rm , and git will monitor that your workspace and repository have changed. See the figure below (or operate doc1.txt to judge). )
As you can see from the almighty git status, you have 2 options.
<1> You really want to delete this file, first git add/rm doc1.txt and then commit to the branch, this is done
<2> If you start the rm operation due to a manual error and want to recover, then you can use checkout to recover
ok, your files are back
It is found that git checkout --<file> can restore the modification and deletion of files.