编程知识 cdmana.com

Git (3) -- index

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 .
git Area

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

HEAD Point to feature

second ,git Will get feautre Branch to the commit and add it to the index

 Add to 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 )

 Index and working 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 ?

 Working directory changes

Now it only affects our working directory , But when we run the following command

git status

git First, it will update index In file Main.java Version of the working directory of

index Change in

Then we see Main.java There are different versions in the working directory and the staging area

index Change in

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

 perform git add After the command

At this point, we execute the order again

git status

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

index Change in

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

 establish commit object

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

Reference article

https://www.youtube.com/watch?v=xbLVvrb2-fY

版权声明
本文为[think123]所创,转载请带上原文链接,感谢

Tags git index
Scroll to Top