git internal principle-git references__svn

9.3 git internal principle-git References Git References

You can perform commands like git log 1a410e to see the complete history, but you should remember that 1a410e is the last time you submitted it so that you can find those objects in the submission history. You need a file to record these SHA-1 values with a simple name so that you can retrieve them using these pointers instead of the original SHA-1 values.

In Git, we call it a "reference" (references or refs, translator note). You can find these files that contain SHA-1 values under the. git/refs directory. In this project, this directory does not contain any files, but contains such a simple structure:

$ find. git/refs.
git/refs.
git/refs/heads.
git/refs/tags
$ find. git/refs-type F
$

If you want to create a new reference to help you remember the last submission, technically you can do this:

$ echo "1a410efbd13591db07496601ebc7a059dd55cfe9" > Git/refs/heads/master

Now, you can use the reference you just created in the Git command instead of the SHA-1 value:

$ git log--pretty=oneline  master
1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
cac0cab538b970a37ea1e769cbbde608743bc96d Second Commit
FDF4FC3344E67AB068F836878B6C4951E3B15F3D

Of course, we do not encourage you to modify these reference files directly. If you really need to update a reference, GIT provides a secure command update-ref:

$ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9

Basically, a branch of Git is actually a pointer or reference to a head record in a working version. You can use this command to create a branch that points to a second commit:

$ git update-ref refs/heads/test cac0ca

Your branch will then include only that submission and the previous work:

$ git log--pretty=oneline test
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
Fdf4fc3344e67ab068f836878b6c4951e3b15f3d

Now, your Git database should look like Figure 9-4.

Figure 9-4. Git directory object that contains branch references

Whenever you perform a command such as Git branch (branch name), Git basically executes the update-ref command, adding the SHA-1 value of the last commit in your current branch to the reference to the branch you are creating. Head Mark

The question now is, how does git know the SHA-1 value of the last commit when you execute GIT branch (branch name) command? The answer is the head file. The head file is a reference identifier that points to your current branch. Such a reference identifier-it does not look like a normal reference-actually does not contain a SHA-1 value, but a pointer to another reference. If you look at this file, you will usually see something like this:

$ cat. Git/head
Ref:refs/heads/master

If you execute git checkout test,git will update this file and look like this:

$ cat. Git/head
Ref:refs/heads/test

When you execute the git commit, it creates a commit object that sets the parent of the commit object to the SHA-1 value of the reference pointed to by head.

You can also edit this file manually, but there is also a more secure way to do this: Symbolic-ref. You can read the head value using the following command:

$ git symbolic-ref head
refs/heads/master

You can also set the head value:

$ git symbolic-ref head refs/heads/test
$ cat. Git/head
Ref:refs/heads/test

But you can't set it in a form other than refs:

$ git symbolic-ref head test fatal:refusing to Point head
outside of refs/

Tags

You've just gone over Git's three main object types, and now this is the fourth kind. The tag object is very much like a commit object--it contains a tag, a set of data, a message, and a pointer. The main difference is that the Tag object points to a commit rather than a tree. It is like a branch reference, but it does not change-always point to the same commit, simply to provide a more friendly name.

As we discussed in chapter II, there are two types of Tag: annotated and lightweight. You can create a lightweight tag similar to the following command:

$ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d

This is the whole of lightweight tag-a branch that will never change. Annotated tag is a bit more complicated. If you create a annotated tag,git, you create a tag object and then write a reference that points to it rather than directly to the commit. You can create a annotated tag like this (a parameter indicates that this is a annotated tag):

$ git tag-a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9-m ' Test tag '

This is the SHA-1 value of the object being created:

$ cat. git/refs/tags/v1.1
9585191F37F7B0FB9444F35A9BF50DE191BEADC2

Now you can run the Cat-file command to check this SHA-1 value:

$ git cat-file-p 9585191f37f7b0fb9444f35a9bf50de191beadc2
object 1a410efbd13591db07496601ebc7a059dd55cfe9
Type commit
tag v1.1
tagger Scott Chacon <schacon@gmail.com> Sat may 16:48:58 2009-0700

Test Tag

It is worth noting that this object points to the SHA-1 value of the Commit object you marked. It is also important to note that it does not have to point to a Commit object, and you can tag any Git object. For example, in Git's source code, a manager adds a GPG public key (which is a BLOB object) to label it. You will be able to run:

$ git cat-file blob junio-gpg-pub

To view the public key in the Git source code warehouse. Linux kernel also has a tag--that does not point to a commit object. The first tag was created when the source code was imported, pointing to the initial tree (the initial tree, the translator's note). Remotes

The fourth kind of reference you will see is the remote reference (the translator note). If you add a remote and push the code past, Git will record the value of each branch you pushed to the remote for the last time in the Refs/remotes directory. For example, you could add a remote named origin and push your master branch up:

$ git Remote add origin git@github.com:schacon/simplegit-progit.git
$ Git push origin master
counting objects:11 , done.
Compressing objects:100% (5/5), done.
Writing objects:100% (7/7), 716 bytes, done.
Total 7 (Delta 2), reused 4 (Delta 1) to
git@github.com:schacon/simplegit-progit.git
   a11bef0. ca82a6d  Master-> Master

Then look at the Refs/remotes/origin/master file and you'll find that the master branch of Origin remote is your last communication with the server.

$ cat. Git/refs/remotes/origin/master
ca82a6dff817ec66f44342007202690a93763949

The main difference between Remote applications and branches is that they cannot be check out. Git treats them as a bookmark that marks the last state of these branches on the server.