Shulou(Shulou.com)05/31 Report--

Most people do not understand the knowledge points of this article "how to create and submit Git index", so the editor summarizes the following, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "how to create and submit Git index" article.

Different index

The Git index is a temporary storage area (staging area) between your working directory (working tree) and the project repository. With it, you can commit many changes to the content together. If you create a commit, the submission is usually the contents of the staging area, not the contents of the working directory.

The status of files in an Git project is roughly divided into the following two categories, while the second category is divided into three subcategories:

1. Untracked files (untracked file)

2. Files that have been tracked (tracked file)

1. Files that have been modified but not temporarily saved (changed but not updated or modified)

2. Files that can be submitted have been temporarily stored (changes to be committed or staged)

3. Files that have not been modified since the last submission (clean or unmodified)

Seeing so many rules above, everyone has already had a big head. The old way, let's build a Git test project to try it out:

Let's start with an empty project:

$rm-rf stage_proj$mkdir stage_proj$cd stage_proj$git initInitialized empty Git repository in / home/test/work/test_stage_proj/.git/

We also create a file with the content "hello, world":

$echo "hello,world" > readme.txt

Now looking at the status of the current working directory, you can see that "readme.txt" is in an untracked state (untracked file):

$git status# On branch master## Initial commit## Untracked files:# (use "git add..." To include in what will be committed) # # readme.txtnothing added to commit but untracked files present (use "git add" to track)

Add "readme.txt" to the temporary storage area: $git add readme.txt

Now look at the status of the current working directory:

$git status# On branch master## Initial commit## Changes to be committed:# (use "git rm-- cached." To unstage) # # new file: readme.txt#

You can see that the status of "readme.txt" is now temporarily available for changes to be committed, which means that the next step is to directly execute "git commit" to submit the file to the local repository.

Staging area is generally stored in the index file (.git / index) in the "git directory", so we sometimes call it index. The index is a binary format file, which stores the information related to the current temporary storage content, including the temporary file name, the SHA1 hash string value of the file content and the file access permission. The contents of the entire index file are stored in order by the temporary file name.

But I don't want to submit the file right away. I'd like to take a look at the contents of the staging area. Let's execute the git ls-files command to have a look:

$git ls-files-- stage100644 2d832d9044c698081e59c322d5a2a459da546469 0 readme.txt

If we have read the "Bao Ding Jie Niu" in the previous article, you will find that there is a file ".git / objects/2d/832d9044c698081e59c322d5a2a459da546469" in the "git directory". If you execute "git cat-file-p 2d832d", you can see that the content inside is "hello,world". When Git adds a file to the scratch area, it not only registers it in the index file (.git / index), but also saves its contents in the "git directory".

If we accidentally add unwanted files to the staging area when executing the "git add" command, we can execute "git rm-- cached filename" to remove the mistakenly added files from the staging area.

Now let's make some changes to the "readme.txt" file:

$echo "hello,world2" > > readme.txt

Let's take a look at the changes in the temporary storage area:

$git status# On branch master## Initial commit## Changes to be committed:# (use "git rm-- cached." To unstage) # # new file: readme.txt## Changed but not updated:# (use "git add..." To update what will be committed) # (use "git checkout--..." To discard changes in working directory) # # modified: readme.txt#

You can see that one more piece has been added to the command output: "changed but not updated. Modified: readme.txt". You may think it is very strange, didn't I add the file "readme.txt" to the temporary storage area? why did it remind me that I did not add it to the temporary storage area (changed but not updated)? is Git wrong?

Git is right. Every time you execute "git add" to add a file to the temporary storage area, it will hash the contents of the file by SHA1, add a new item to the index file, and store the contents of the file in the local "git directory". If the contents of the file are modified after the last execution of "git add", then when the "git status" command is executed, Git will hash the contents of the file and find that the file has been modified again, and then "readme.txt" presents two states at the same time: the file that has been modified but not temporarily saved (changed but not updated), and the file that can be submitted temporarily (changes to be committed). If we submit at this time, we will only submit the content of the file that is temporarily saved because of "git add" for * times.

I am not satisfied with the modification of "hello,world2" now. To undo this change, you can execute the command "git checkout":

$git checkout-readme.txt

Now let's take a look at the status of the working directory in the warehouse:

$git status# On branch master## Initial commit## Changes to be committed:# (use "git rm-- cached." To unstage) # # new file: readme.txt#

OK, now that the project is back to the state I want, I will submit this change with the git commit command:

$git commit-m "project init" [master (root-commit) 6cdae57] project init 1 files changed, 1 insertions (+), 0 deletions (-) create mode 100644 readme.txt

Now let's look at the status of the working directory:

$git status# On branch masternothing to commit (working directory clean)

You can see "nothing to commit (working directory clean)"; if all the changes in a working tree (working tree) have been committed to the current branch (current head), then it is said to be clean (clean), otherwise it is dirty (dirty).

SHA1 value content addressing

As stated in the article Git is the next Unix, Git is a completely new way of using data (Git is a totally new way to operate on data). Git takes all the objects it manages (blob,tree,commit,tag...) All generate SHA1 hash string values as object names based on their contents; according to current mathematical knowledge, if the SHA1 hash string values of two pieces of data are equal, then we can assume that the two pieces of data are the same There are several benefits that this will bring:

Git can quickly determine whether the contents of two objects are the same by comparing object names.

Because the method of calculating the "object name" in each repository is exactly the same, if the same content exists in two different repositories, the same "object name" exists.

Git can also determine whether the object content is correct by checking whether the SHA1 hash value of the object content matches the "object name".

Let's use the following example to verify whether what is said above is true. Now create a file "readme2.txt" with exactly the same content as "readme.txt", and then submit it to the local repository:

$echo "hello,world" > readme2.txt$git add readme2.txt$git commit-m "add new file: readme2.txt" [master 6200c2c] add new file: readme2.txt1 files changed, 1 insertions (+), 0 deletions (-) create mode 100644 readme2.txt

The following complex command is to look at the blob objects contained in the current HEAD:

$git cat-file-p HEAD | head-N1 | cut-b6-15 | xargs git cat-file-p100644 blob 2d832d9044c698081e59c322d5a2a459da546469 readme.txt100644 blob 2d832d9044c698081e59c322d5a2a459da546469 readme2.txt

Let's take a look at the blob object contained in the last commit (head ^):

$git cat-file-p head ^ | head-n 1 | cut-b6-15 | xargs git cat-file-p100644 blob 2d832d9044c698081e59c322d5a2a459da546469 readme.txt

You can obviously see that although the current submission has one more file than the previous one, they share the same blob object: "2d832d9".

No delta, just snapshot

There is a big difference between Git and most version control systems you are familiar with, such as Subversion, CVS, and Perforce. Traditional systems use "incremental file systems" (Delta Storage systems), which store the differences between each commit. On the contrary, Git saves the complete content of each submission (snapshot); it asks for the SHA1 hash string value as the object name according to the content to be submitted before submission, to see if there are the same objects in the warehouse, if not, the corresponding objects will be created in the ".git / objects" directory, and if there is, the existing objects will be reused to save space.

Let's try to see if Git really saves the submitted content in a "snapshot" way.

First modify "readme.txt", add some content to it, then temporarily store it, and * submit it to the local warehouse:

$echo "hello,world2" > > readme.txt$git add readme.txt$git commit-m "add new content for readme.txt" [master c26c2e7] add new content for readme.txt 1 files changed, 1 insertions (+), 0 deletions (-)

Let's now look at what blob objects are included in the current version:

$git cat-file-p HEAD | head-N1 | cut-b6-15 | xargs git cat-file-p100644 blob 2e4e85a61968db0c9ac294f76de70575a62822e1 readme.txt100644 blob 2d832d9044c698081e59c322d5a2a459da546469 readme2.txt

From the above command output, we can see that "readme.txt" already corresponds to a new blob object: "2e4e85a", while the blob object corresponding to the previous version of "readme.txt" is: "2d832d9". Let's take a look at whether the contents of these two "blob" are the same as our expectations:

$git cat-file-p 2e4e85ahellogic worldhellowrityworld2 $git cat-file-p 2d832d9helloMagi world

As you can see, the contents of each submission are still saved (snapshot).

The above is about the content of this article on "how to create and submit Git Index". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.