The following diagram shows the relationship between the workspace, the staging area in the repository, and the repository:
1. Understand the Git staging area (stage)
There is an index file in the .git directory of the repository. Let's do an interesting experiment with this file. It should be noted that this experiment was conducted with the 1.7.3 version of Git. Because the lower version of Git is not optimized for the git status command, it is necessary to run the git diff command to see the date stamp change of the index file. The specific operation steps are as follows .
(1) First execute the git checkout command (this command will be introduced later) to undo the uncommitted modifications to the welcome.txt file in the workspace.
git checkout -- welcome.txt git status -s #Execute git diff, if the git version number is less than 1.7.3
(2) Through the status output, it can be seen that the work area has not been changed. Take a look at the .git/index file and note that the timestamp of the file is: 19:37:44
ls --full-time .git/index -rw-rw-r-- 1 git git 104 2018-05-03 19:37:44.492022847 +0800 .git/index
(3) Execute the git status command again, and then display the timestamp of the .git/index file as 19:37:44, the same as above.
git status -s ls --full-time .git/index
-rw-rw-r-- 1 git git 104 2018-05-03 19:37:44.492022847 +0800 .git/index
(4) Now change the timestamp of welcome.txt, but not its content. Then execute the git status command again to see that the timestamp of the .git/index file is: 19:42:06.
touch welcome.txt git status -s -rw-rw-r-- 1 git git 104 2018-05-03 19:42:06.830558718 +0800 .git/index
See, the timestamp has changed!
This test shows that when executing the git status command (or git diff command) to scan the workspace for changes, first judge the workspace file based on the timestamp, length and other information recorded in the .git/index file (used to track work and files) Whether it has changed, if the timestamp of the workspace file has changed, it means that the content of the file may have been changed. It is necessary to open the file, read the content of the file, and compare it with the original file before the change to determine whether the content of the file has been changed. If the file contents have not changed, the new timestamp of the file is recorded in the .git/index file. Because if you want to determine whether a file has changed, it is much faster to use timestamp, file length and other information to compare than to compare by file content, so Git's implementation method can make the workspace status scan performed faster, which is also Git efficient one of the reasons.
The file .git/index is actually a directory tree containing the file index, like a virtual workspace. In the directory tree of this virtual workspace, the file name and file status information (timestamp and file length, etc.) are recorded. The content of the file is not stored in it, but in the .git/objects directory of the Git object repository, and the file index establishes the correspondence between the file and the object entity.
Figure 5-1 shows how some of the Git commands affect the workspace and staging area. The veil of these commands will be completely lifted in the next few chapters, and the following is a brief description of these commands:
- The left side of the figure is the workspace, and the right side is the repository. The area marked index in the repository is the staging area , and the one marked master is the directory tree represented by the master branch.
- As can be seen from the figure, HEAD is actually a "cursor" pointing to the master branch at this time, so the place where HEAD appears in the command shown in the figure can be replaced by master.
- The area identified by objects in the figure is the Git object library, which is actually located in the .git/objects directory, which will be highlighted in the following chapters.
- When the git add command is executed on the modified (or newly added) files in the workspace, the directory tree in the staging area will be updated, and the contents of the modified (or newly added) files in the workspace will be written to one of the object libraries new object, and the ID of the object is recorded in the file index of the staging area.
- When the commit operation (git commit) is performed, the directory tree in the staging area will be written to the repository (object repository), and the master branch will be updated accordingly , that is, the directory tree pointed to by master is the original staging area at the time of submission. directory tree. (ie: master = staging area)
- When the git reset HEAD command is executed, the directory tree in the staging area will be rewritten and replaced by the directory tree pointed to by the master branch, but the workspace will not be affected. (ie: staging area = master)
- When the git rm --cached <file> command is executed, the file will be deleted directly from the staging area, and the workspace will not be changed.
- When the git checkout . or git checkout -- <file> command is executed, the files in the workspace will be replaced with all the files in the staging area or the specified files. This operation is dangerous and will clear changes from the workspace that were not added to the staging area.
- When the git checkout HEAD . or git checkout HEAD <file> command is executed, all or part of the files in the master branch pointed to by HEAD are used to replace the files in the staging area and work area . This command is also extremely dangerous, as it will clear not only committed changes in the workspace, but also uncommitted changes in the staging area.