Temporary storage area
from gi t From the perspective of , The revision of the document involves the following three areas : working directory , stage District ( Temporary storage area ) And the local warehouse .
When we made some changes to our project ( The new file , Delete file , Modify documents, etc ), What we're dealing with is our working directory . This directory exists on our computer's file system . All changes will remain in the working directory until we add them to the staging area ( adopt git add command ).
This is the best representation of the next commit , When we execute
git commit,git Will get the changes in the staging area , And make these changes the next submission . One of the practical functions of the staging area is to allow you to adjust your submission , You can add and delete changes to the staging until you are satisfied with your next submission , This is when you can use
git commit Submitted your content .
After submitting the changes , They will enter
.git/objects Catalog , In which it is preserved as commit,blob as well as tree objects,( Reference resources Data model That article )
It's not accurate to think of the staging area as a real area to store changes ,git No special stage Directory to store changes to these files (blobs),git There is one named index To track changes in these three areas : working directory , Staging area and local warehouse .
When we add changes to the staging area ,git Will update index Information in the file , And create a new blob object, And then put them into the other... Generated by the previously submitted records blob same .git/objects Directory .
index The change of
And then we go through a normal git Let's demonstrate the process git How to use index
First of all, we have... In our warehouse master as well as feature Two branches , If we carry out the following order , Three things will happen
git checkout feature
First of all ,git Mobile HEAD The pointer points to feature Branch , To make it easier to understand , We only show the last commit of the functional branch
second ,git Will get feautre Branch to the commit and add it to the index
We noticed that index It's a file, not a directory , therefore git There's no storage in it ,git It's just storing information about every file in our warehouse , It's similar to the above
mtime : Last updated file : File name wdir : File version in working directory stage : index Version of Chinese document repo : File version in warehouse
File versions are identified by checksums , If two files have the same checksums , So they have the same content and version .
Last ,git Will put your working directory and HEAD The content that points to matches ( It will use trees and blob Object to recreate the contents of the project directory )
therefore , When you use checkout When , working directory , Both the staging area and the warehouse are the same version
Let's see when we edit Main.java What happens when ?
Now it only affects our working directory , But when we run the following command
git First, it will update index In file Main.java Version of the working directory of
Then we see Main.java There are different versions in the working directory and the staging area
then git Will remind us
On branch feature Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: Main.java no changes added to commit (use "git add" and/or "git commit -a")
This means that the changes to the working directory are not in the staging area ( Then the next submission will not contain Main.java Modification of ).
therefore , Execution of the following command will Main.java Add to staging area
git add Main.java
The above command was carried out , Two things will happen again , First of all ,git Would be Main.java Create a blob object Then stored in .git/objects Under the table of contents , second , Will be updated again index file
At this point, we execute the order again
git Will find Main.java The version of the staging area is the same as the working directory version , But it doesn't match the version of the warehouse
therefore git Just tell us
On branch feature Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: Main.java
prove Main.java It's already in the staging area , But it hasn't been submitted to the warehouse yet . Now we can submit our changes
git commit -m "add some code to Main.java"
git Can do the following things :
1. newly added commit object and tree object, And put them into practice git add Created when blob object Connect 2. Move feature The pointer to the new commit object 3. to update index
All right. , Now our Main.java There's the same version in all regions .
No matter to perform
git add still
git commitindex Files will change , This is also a better proof of our model , Of course index The contents of the document are certainly not so clear , It's a binary , If you want to see its content, you need to use other tools to implement it
It's about git index How does it work , Now looking back, it's not really complicated , But for us to understand in some of the index On the operation of the command (add,checkout,revert,commit,add...) But it's crucial