Git
章节 ▾ 第二版

10.3 Git 内部机制 - Git 引用

Git 引用

如果你想查看从某个提交(比如 1a410e)开始可以访问到的仓库历史,你可以运行类似 git log 1a410e 的命令来显示该历史,但是你仍然需要记住 1a410e 是你想要用作该历史起始点的提交。相反,如果你有一个文件,可以在其中将该 SHA-1 值存储在一个简单的名称下,这样你就可以使用这个简单的名称而不是原始的 SHA-1 值,这会更容易一些。

在 Git 中,这些简单的名称被称为“引用”或“refs”;你可以在 .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 <branch> 这样的命令时,Git 基本上会运行 update-ref 命令,将你当前所在分支的最后一个提交的 SHA-1 添加到你想创建的任何新引用中。

HEAD

现在的问题是,当你运行 git branch <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 的三种主要对象类型(blobtreecommit),但还有第四种。标签对象非常类似于提交对象——它包含一个标签者、一个日期、一个消息和一个指针。主要区别在于标签对象通常指向提交而不是树。它就像一个分支引用,但它永远不会移动——它总是指向同一个提交,但给它一个更友好的名称。

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 <[email protected]> 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 [email protected]: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 [email protected]:schacon/simplegit-progit.git
  a11bef0..ca82a6d  master -> master

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

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

远程引用与分支(refs/heads引用)的主要区别在于,它们被视为只读。您可以git checkout到其中一个,但 Git 不会将 HEAD 符号引用到其中一个,因此您永远不会使用commit命令更新它。Git 将它们管理为书签,指向这些分支在这些服务器上的最后一个已知状态。

scroll-to-top