How git works-how files are stored

how git works-how files are stored

has always been very curious about the storage principles of git, so today it's a special study, a record of the process of research.

Let's consider this directory structure as an example,

First, the CD Gittest directory, initialized with the git init command, after executing this command after the Gittest directory to generate a. git file, we look at the file under the content, as follows:

Then execute:
Git add–all
Git commit-am "Commit 1 ... ”
This gives us a first look at the objects directory, and Git will save all the changed files in the. git/objects/folder and look at the contents:
1.git File Object

Git's file objects are divided into four categories: blob, tree, commit, tags.

Git-managed files exist as BLOB types, while catalog files exist as tree types, and several blobs and tree files can be referenced inside a tree type.

That is, when we execute a commit, GIT will create a set of blob and tree files in objects according to the directory structure of our project, but our example project has only two files and a folder, why objects There are five files that, This is about the commit type, which can reference a tree type file and a commit type file inside the commit type.

About the name of the file, objects internal files are all named Sha-1, if the BLOB type is the file content to do sha-1 calculate the checksum of 40 characters, and then in order not to let this objects internal file too much, So use the first two of the 40 characters to create a folder, at the next 38 bits for the file name, including commit and tree all use Sha-1 checksum to name.
Take a look at what the structure of these five files is associated with:
Each commit references a tree, according to the project directory structure The tree is referencing a blob (a.txt) and a tree (BB), The tree (BB) refers to a blob (B.txt) as shown in figure:

Through this graph can see Commit,tree,blob relationship, also basic can understand why objects under five files,
Now I'm going to change the a.txt. Then, in submitting a version, add 22222222222 content in A.txt to execute Add and commit, add a version, and then look inside the objects:

More than just three files, which is the three files. Since we have changed the A.txt file, we have added a new a.txt file on top of the previous version of A.txt, and git only backs up the changed files. The other two files are commit 2 and a root tree, and now the relationship of these 8 files is as follows: A commit can be referenced within the

commit file, so that a relationship can be established between commits. Because only the a.txt file has been changed so that only the A.txt file is created, and then referenced by Commit2, BB and b.txt files are not changed Commit2 still refer to the previous file. Similarly, if we change the B.txt file again, we can imagine the correlation between these files. Figure:
2.branch Branch

Git branch can get the current list of branches, this branch list will be saved in the./git/refs/heads/path, which contains master and some other branch files, in the master file as an example to see the contents of the master file as follows:

This is actually a file name of the commit type, so that each branch can have its own commit reference, from the above figure can be seen as long as the file name of the commit can find all the files associated with him, there is a problem./git/refs/heads/ This file is all branch information, always have a current branch, in fact, this current branch is recorded in the./git/head file inside the view:
because it is currently the master branch, so the head file is the master, each time we git checkout To switch branches is to modify the head of this piece of content. Then we can basically understand that we first select a branch as the current branch, each branch of the current branch of the topmost commit object, the Commit object can find all associated with it tree and blob, while the commit object and its historical commit association. We can switch the current branch arbitrarily, and we can modify the commit object that the current branch points to, such as we can choose to fall back to any commit when we perform reset. This makes it logical to switch any branch and find any version of the file.