章节 ▾ 第二版

10.3 Git 内部原理 - Git 引用

Git 引用

如果你对查看仓库中从提交 1a410e 开始可访问的历史记录感兴趣，你可以运行类似 git log 1a410e 的命令来显示该历史记录，但你仍然需要记住 1a410e 是你想要作为该历史记录起点的提交。相反，如果你有一个文件可以存储该 SHA-1 值，并用一个简单的名字来表示，这样你就可以使用这个简单的名字而不是原始的 SHA-1 值，那会更容易。

在 Git 中，这些简单的名字被称为“引用”或“ref”；你可以在 .git/refs 目录中找到包含这些 SHA-1 值的文件。在当前项目中，这个目录不包含文件，但它确实包含一个简单的结构

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

要创建一个新的引用来帮助你记住最新提交的位置，你可以简单地这样做

$ echo 1a410efbd13591db07496601ebc7a059dd55cfe9 > .git/refs/heads/master

现在，你可以在 Git 命令中使用你刚刚创建的 head 引用，而不是 SHA-1 值

$ git log --pretty=oneline master
1a410efbd13591db07496601ebc7a059dd55cfe9 Third commit
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit

不鼓励你直接编辑引用文件；相反，Git 提供了更安全的命令 git update-ref 来实现这个目的，如果你想更新引用的话

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

这基本上就是 Git 中的分支：一个指向工作线头部的简单指针或引用。要在第二个提交处创建一个分支，你可以这样做

$ git update-ref refs/heads/test cac0ca

你的分支将只包含从该提交向下衍生的工作

$ git log --pretty=oneline test
cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit

现在，你的 Git 数据库概念上看起来像这样

Git directory objects with branch head references included
图 176. 包含分支头引用的 Git 目录对象

当你运行诸如 git branch 这样的命令时，Git 基本上会运行 update-ref 命令，将你当前所在分支的最后一次提交的 SHA-1 添加到你想要创建的任何新引用中。

HEAD

现在的问题是，当你运行 git branch 时，Git 如何知道最后一次提交的 SHA-1？答案是 HEAD 文件。

通常，HEAD 文件是你当前所在分支的符号引用。所谓符号引用，我们的意思是，与普通引用不同，它包含指向另一个引用的指针。

但在某些罕见情况下，HEAD 文件可能包含 Git 对象的 SHA-1 值。这发生在你检出标签、提交或远程分支时，这会使你的仓库处于 “分离 HEAD” 状态。

如果你查看该文件，你通常会看到这样的内容

$ cat .git/HEAD
ref: refs/heads/master

如果你运行 git checkout test，Git 会更新文件，使其看起来像这样

$ cat .git/HEAD
ref: refs/heads/test

当你运行 git commit 时，它会创建提交对象，并将该提交对象的父级指定为 HEAD 中引用指向的任何 SHA-1 值。

你也可以手动编辑这个文件，但同样存在一个更安全的命令来完成此操作：git symbolic-ref。你可以通过此命令读取 HEAD 的值

$ git symbolic-ref HEAD
refs/heads/master

你也可以使用相同的命令设置 HEAD 的值

$ git symbolic-ref HEAD refs/heads/test
$ cat .git/HEAD
ref: refs/heads/test

你不能在 refs 样式之外设置符号引用

$ git symbolic-ref HEAD test
fatal: Refusing to point HEAD outside of refs/

标签

我们刚刚讨论了 Git 的三个主要对象类型（blob、tree 和 commit），但还有第四种。tag 对象与 commit 对象非常相似——它包含一个打标签者、一个日期、一条消息和一个指针。主要区别在于 tag 对象通常指向一个提交而不是一个树。它就像一个分支引用，但它从不移动——它总是指向同一个提交，但给它一个更友好的名字。

正如在 Git 基础 中讨论的，标签有两种类型：带注解的和轻量级的。你可以通过运行类似这样的命令来创建一个轻量级标签

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

这就是轻量级标签的全部内容——一个永不移动的引用。然而，带注解的标签更复杂。如果你创建一个带注解的标签，Git 会创建一个标签对象，然后写入一个引用来指向它，而不是直接指向提交。你可以通过创建一个带注解的标签（使用 -a 选项）来查看这一点

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

这是它创建的对象 SHA-1 值

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

现在，对那个 SHA-1 值运行 git cat-file -p

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

Test tag

请注意，对象条目指向你打标签的提交 SHA-1 值。还要注意，它不需要指向一个提交；你可以标记任何 Git 对象。例如，在 Git 源代码中，维护者已将他们的 GPG 公钥添加为 blob 对象，然后对其进行了标记。你可以在 Git 仓库的克隆中运行此命令来查看公钥

$ git cat-file blob junio-gpg-pub

Linux 内核仓库也有一个不指向提交的标签对象——创建的第一个标签指向源代码导入的初始树。

远程

你会看到的第三种引用类型是远程引用。如果你添加一个远程并推送到它，Git 会在 refs/remotes 目录中存储你上次推送到该远程的每个分支的值。例如，你可以添加一个名为 origin 的远程，并将你的 master 分支推送到它

$ 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

然后，你可以通过检查 refs/remotes/origin/master 文件，查看你上次与服务器通信时 origin 远程上的 master 分支是什么

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

远程引用与分支（refs/heads 引用）的主要区别在于它们被认为是只读的。你可以 git checkout 到一个，但 Git 不会象征性地将 HEAD 引用到它，所以你永远不会通过 commit 命令更新它。Git 将它们作为这些分支在这些服务器上的最后已知状态的书签进行管理。