preface
The last section focused on installing and configuring Git. Git is used to store code, so Git is essentially a database. This section focuses on the concept of regions and objects in Git.
An area of,
The workspace
The workspace, from its name, can be understood as the area at work, the page on which we write the code. Git does not manage files that are in the workspace. Create a folder on your desktop that is a workspace, but not a Git repository.
The staging area
A staging area is an area where things are stored temporarily, so why do you need a staging area? In fact, the truth is very simple, my project is divided into multiple modules, one module is completed and does not need to change, then it can be put into the staging area. The contents of the staging area are part of the project content, so the staging file Git is managed. Open the folder you just created, right-click inside it, select Git Bash Here, and type Git init on the command line interface to start your Git repository. (PS: If you can’t see. Git folder is probably not checked to show hidden files)
Info: contains a global exclusion file (which contains files that do not need Git management). Store all data content. Refs: pointer to the commit object that holds data (branches). (PS: this will be explained later when discussing branches) Config: Records some configuration information about the project. Description: Describes the warehouse. HEAD: indicates the branch currently detected. The contents of the folder are all introduced, SO~ which is the temporary storage area? There is currently no staging area because there is nothing to store in the staging area. – -! If there was a staging area his name would be Index!!
repository
A repository is a collection of files in the staging area. That repository must also be managed by Git. The.git folder shown above is the repository
So we understand that the workspace files go to the staging area first, and then the staging files go to the repository, but this needs to be verified.
Second, the object
Git object
At the heart of Git is a simple key-value data store. You can insert any type of content into a Git repository, and it returns a unique key that can be retrieved again at any time. Command: echo ‘example code’ | git hash – object – w – the stdin -w option instructs hash – object commands stored data object; Without -w, simply return the key value (the key value is a 40-character checksum). Is a SHA-1 hash) can only be stored in the database (repository) if -w is added. The –stdin option indicates that the command reads from standard input, if it does not specify a path with write files at the end of the command. Git hash-object-w Specifies the file path
Since Objects is where Git keeps all of its content, you can see whether it has been stored or not by looking here. You can see that the first two bits of the returned hash are used as the folder name and the last bits are used as the file name, with different keys depending on the content.
Git cat-file -p git cat-file -p git cat-file -p git cat-file -p In the command, -p can automatically determine the file type and display it in a friendly format.
You can’t view the key without adding -w, because it is not stored in the Git repository. We store and control files on a daily basis rather than getting content from standard input, so I’ll give you a rough demonstration.
Git objects are key/value pairs (key:val). Git cat-file -t Git cat-file -t Git cat-file -t Git cat-file -t Git cat-file -t Git cat-file -t Git cat-file -t Git cat-file -t Git You can see what the object is, and you can see from the command that the key-value pair is of type BLOB. Problem: A Git object can only represent a version of a file, not a version of a project, and it only stores the contents of the file, not the file name. Note: currently all operations are performed in the local database and do not involve registers, putting the data content directly into the repository.
The tree object
Tree objects can solve the problem of file name preservation, allowing multiple files to be organized together. Git stores content in a manner similar to Unix file systems. All content is stored as tree objects, which correspond to Unix directory entries, and data objects (Git objects), which roughly correspond to file contents. A tree object can contain one or more records (each record contains a hash pointer to a Git object or count object, along with the corresponding schema, type, and file name information). A tree object can contain another tree object. Build a number object: we use updata-index; write-tree; Commands such as read-tree build tree objects and place them in the cache. Run the updata-index command to create a staging area for the first version of the test. TXT file, and run the write-tree command to generate number objects. Git updata-index-add –cacheinfo 100644 test. TXT git write tree 100644 — is a common file; 100755 — Executable file; 120000 — a symbolic link. –add option: Since the file was not in the cache before, you need to add the –add option for the first time. — cacheInfo option: You need to place the added file in your Git database, not the current directory. Create a staging area using updata-index. Create a staging area using updata-index. Create a staging area using updata-index.
// Create the contents of text.txt for the first time
$ git cat-file -p 5e53748853d0671d366289e2433d3e50efd4d987
Jc example
// Modify the contents of text.txt
$ git cat-file -p be4da39b20d70d9389d76fe4ce388ef0c107a8eb
Jc example
Jc test
// What is written from standard input for the first time
$ git cat-file -p ba04de12e181335304d9ddb633d8c575ea788a10
example code
// The index file appears in the.git folder after executing this command. This command does not write anything to the repository. It simply generates a record in the staging area and gives the git object a name
$ git update-index --add --cacheinfo 100644 5e53748853d0671d366289e2433d3e50efd4d987 -First.txt
$ git update-index --add --cacheinfo 100644 ba04de12e181335304d9ddb633d8c575ea788a10 -Second.txt
// To view the contents of the staging area, run the following command
$ git ls-files -s
100644 5e53748853d0671d366289e2433d3e50efd4d987 0 -First.txt
100644 ba04de12e181335304d9ddb633d8c575ea788a10 0 -Second.txt
// Check that the contents of the version library are not added
$ find ./.git/objects/ -type f
./.git/objects/5e/53748853d0671d366289e2433d3e50efd4d987
./.git/objects/ba/04de12e181335304d9ddb633d8c575ea788a10
./.git/objects/be/4da39b20d70d9389d76fe4ce388ef0c107a8eb
Copy the codeNow there are two files in the staging area, first.txt and second.txt. Assuming these two files will complete the First version of the project, we should generate a tree object. Git Write Tree generates a tree object, as you can see below.
Git read-tree –prefix=bak git read-tree –prefix=bak git read-tree –prefix=bak git read-tree –prefix=bak We create a file and write it to the cache. This file and a number object form a new number object.
At present the relationship is a bit complicated, then see the following map!! It must make sense when you look at the picture.
Git object is the version of a file. A version of a project should have at least two objects (polygamy?? Are they all good friends? . The e problem: tree objects solve the versioning problem, but if you want to count objects, you need to remember the hash value. It is also not known who saved the snapshot (interpreted as the version of the project) or what the snapshot does. These problems are left to the submitter to resolve.
Submit the object
Commit objects can be created using the commit-tree command, which requires a hash of the tree object and the parent of the commit object (if none exists, Git commit-tree specifies the hash value of the parent of the commit object. A picture is worth a thousand words. Here you can see the information we configured in the first section of the notes.
Submit object summary: So the tree object is the version of the project, the submit object is just some comment information to the tree object, but the submit object is a linked list structure that can be connected together. Git stores snapshots of your project, not deltas, so if you want to roll back the version, you only need to know the hash value of the submitted object.
Third, the end
Git command base is basically complete, if feel useful can click a “like” oh! I will continue to update, if there are any mistakes please point out, thank you for your audience master.
To get a PDF of the above content, go to GitHub and download it.
Address: Git study notes area
— — — — — a romantic