Git Step by step– (4) Explore. Git directory

The previous article introduced the Git object model, and then we went to the ". Git" directory to see what was going on and what in the directory was related to the Git object model. With this directory, we'll learn more about how git works.

. Git directory

The following is the beginning of the. git directory, with the "LS" command to see the files and subdirectories in the. Git directory:

For these files and directories, some basic descriptions are given below. Later, logs, objects, refs, index, and head are described in more detail.

• (D) Hooks: This directory contains some shell scripts that can be set up with specific GIT commands and the corresponding scripts will be used when building a gitweb system or other Git hosting system.
• (D) Info: Contains some information about the warehouse
• (D) Logs: Save all updated reference records (references are described later)
• (D) objects: All Git objects will be stored in this directory, the first two bits of the SHA1 hash of the object are the folder name, and the last 38 bits as the object file name
• (D) Refs: This directory typically includes three subfolders: Files in heads, remotes, and tags,heads identify the current commit that each branch in the project points to
• (F) Commit_editmsg: Save the latest COMMIT Message,git system will not use this file, just give the user a reference
• (F) Config: This is the configuration file for the Git repository
• (F) Description: A description of the warehouse, primarily for use with git managed systems such as Gitweb
• (F) Index: This file is the one we mentioned in the previous Article staging area (stage), is a binary file
• (F) HEAD: This file contains a reference to the current branch (branch), through which git can get the next commit of the parent
• (F) Orig_head:head the previous state of the pointer

git references

The reference in Git is a very important concept and is very helpful for understanding branching (branch), head pointers, and Reflog.

The branch name, remote branch name, tag, and so on in the GIT system are references to a commit. For example, the master branch, origin/master remote branch, tag named V1.0.0.0, and so on are references, which point to a commit by saving a commit's SHA1 hash value.

Re-recognize head

Head is also a reference, which in general is directed to the latest commit on the branch you are currently on. Unlike the generic reference in Git, which does not contain a commit's SHA1 hash, it contains the current branch, so head points directly to the current branch and then indirectly to the latest commit of the current branch.

For a more descriptive explanation of the above description, we first look at the contents of ". Git/head":

Ref:refs/heads/master

This means that the head is a reference to the Master branch, and then we can open the "refs/heads/master" file according to the reference path, which reads as follows:

4ea6c317a67e73b0befcb83c36b915c1481f2efe

According to the previous article, we look at the object type and content through this hash value, we can see that the hash value corresponds to a commit, and through "git log" can be found that this commit is the master branch of the latest commit.

So we can see that all the content is interlocking, we find a current branch through head, and then we find the latest commit through the reference of the current branch, and then we can find the whole object relational model through commit, see:

References and branches

Until now we have not started to introduce branches (branch), and here is not going to introduce branches, just want to show the relationship between references and branches.

Suppose we now, in addition to the Master branch, create a release-1.0.0.1 branch and look again at the ". git/refs/heads/" directory, you can see that in addition to the master file, One more release-1.0.0.1 file, and the contents of the file to be viewed are also a hash value.

The "Git show-ref--heads" command makes it possible to see all the headers, which are the head's candidate values:

According to the previous explanation, this commit is the latest commit on the release-1.0.0.1 branch. Similarly, when we switch the current branch to release-1.0.0.1, the contents of the head file are changed accordingly:

ref:refs/heads/release-1.0. 0.1

Look at Reflog again.

Students who have read the second article must remember how we got a commit hash based on Reflog and then returned the repo to a specified state.

Next, we go to the ". Git/logs" folder, you can see that this folder also has a head file and the refs directory, some of the records Reflog place.

View the contents of the head file and find that the file will contain Reflog records for all branches:

0000000000000000000000000000000000000000601B527296FEA232C84B3661ABCBFF0576B1272C Wilbertian <Wilber***.com>1419759347+0800commit (initial): Add calc.py into repo601b527296fea232c84b3661abcbff0576b1272c c2163e267380f71373f29f922e7089abbb741772 Wilbertian<Wilber***.com>1419769538+0800Commit:add Subfunction inchcalc.pyc2163e267380f71373f29f922e7089abbb741772 4ea6c317a67e73b0befcb83c36b915c1481f2efe WilberTian<Wilber***.com>1419771391+0800Commit:add app.py, __init__.py and Calc.py4ea6c317a67e73b0befcb83c36b915c1481f2efe 4ea6c317a67e73b0befcb83c36b915c1481f2efe Wilbertian<Wilber***.com>1419822744+0800Checkout:moving from Master to release-1.0.0.1

Enter the ". Git/logs/refs" directory, with the same master and release-1.0.0.1 two files, and two files will save the Reflog records of their respective branches.

Content of Master:

0000000000000000000000000000000000000000 1419759347 +0800    1419769538 +0800    functionin 1419771391 +0800  commit:add app.py, __init__.py and calc.py     

Content of release-1.0.0.1:

0000000000000000000000000000000000000000 1419822744 +0800    branch:created from Master

git indexing (index)

We also mentioned in the previous article Index/stage, is the update of the staging area, the following to see the index file.

Index shows a binary file that holds the sorted path, and each path corresponds to a SHA1 hash value. In a git system, you can display the contents of the index file through "Git ls-files--stage":

From the output of the command, you can see that all records correspond to the files in the repository (including the full path). You can see that this hash is the Blob object representing the app.py by looking at the hash value of the app.py with the "Git cat-file" command.

Now that we update the app.py file with a "div (16, 4)" Call and add it to staging area with "Git add", we find that the hash value of the App.py object in index has changed.

With this example, we can also understand how the diff operation should be output:

• git diff: diff output before compare workspace and Stage,add, no diff output after add
• git diff HEAD: diff output after comparing workspace and Repo,add
• git diff--cached: there is no diff output before the stage and Repo,add, and the diff output after add

Storage of objects

As mentioned above, all Git objects are stored in the ". Git/objects" Directory, the first two bits of the object SHA1 hash are the folder name, and the last 38 bits as the object file name.

So, the hash value of the newest commit object in the master we mentioned earlier is "4ea6c317a67e73b0befcb83c36b915c1481f2efe", then this object is stored in the ". git/objects/4e/ A6c317a67e73b0befcb83c36b915c1481f2efe ". After entering the objects directory, we did find this file.

There are two ways to store objects in a git system, such as loose object storage and packaged object storage.

Loose objects (Loose object)

Loose object storage is mentioned earlier, each object is written to a separate file, the first two bits of the object SHA1 hash are the folder name, and the last 38 bits as the object file name.

Packaging objects (Packed object)

For loose storage, each version of each file is used as a separate object, it is less efficient and wastes space. So there's a way to store it through a packaged file (Packfile).

Git uses packaged files (packfile) to save space. In this format, Git saves only the changed parts of the second file, and then points to the similar file with a pointer.

The general git system will automatically complete the package, and in the Git repository that has already been packaged, a lot of "pack-***.idx" and "Pack-***.pack" files will appear in the ". Git/objects/pack" directory. So much has been said about packaging that we haven't studied the contents and principles of the two files for the time being.

Summarize

This article combines the Git object model of the previous article and explores the. git folder, with references, Reflog, and an introduction to the index, and I'm sure you'll learn more about how git works.

Through the two articles introduced down, feel the same git also slowly familiar with the puzzle.

Git Step by step– (4) Explore. Git directory