第一个关键词“头”（英文为全部字母小写）是 Git 为每个新建的提交对象维护的引用。为了阐明具体工作方式，图 8 展示了多个提交和分支操作。对于提交 01，Git 为存储库创建了第一个头引用，并将其默认命名为“master”（master 是没有任何特殊含义的任意名称，只是一个默认名称而已，Git 团队经常会重命名此引用）。新建头引用后，Git 会在 refheads 文件夹中创建一个文本文件，并将新提交对象的完整 SHA‑1 置于此文件中。对于提交 01，也就是说，Git 会创建一个名为“master”的文件，并将提交对象 A1 的 SHA-1 置于此文件中。对于提交 02，Git 会删除旧 SHA-1 值，并将其替换成 A2 的完整 SHA-1 提交 ID，从而更新 heads 文件夹中的 master 头文件。Git 会对提交 03 执行相同操作： 它会将 heads 文件夹中的 master 头文件更新为包含 A3 的完整提交 ID。

图 8：2 个头好过 1 个头：Git 在 heads 文件夹中维护各种文件以及一个 HEAD 文件

大家可能已经猜到，heads 文件夹中的 master 文件就是它指向的提交对象的分支名称。奇怪的是，分支名称也许最初指向一个提交对象，而不是一系列提交对象（我很快就会详细介绍这一特定概念）。

请观察图 8 中的“创建分支和签出文件”部分。其中，用户在 Visual Studio 中为打印预览功能新建了一个分支。用户将此分支命名为 feat_print_preview，让其以 master 为依据，然后在团队资源管理器的“从选定项创建本地分支”窗格中选中了“签出分支”复选框。选中此复选框即指示 Git 要让新分支成为当前分支（我很快就会对此进行解释）。在后台，Git 在 heads 文件夹中新建了一个 feat_print_preview 头文件，并将提交对象 A3 的 SHA-1 值置于其中。也就是说，现在 heads 文件夹中包含以下两个文件：master 和 feat_print_preview。这两个文件都指向 A3。

在提交 04 中，Git 需要做出一项决定： 通常情况下，它会更新 heads 文件夹中文件引用的 SHA-1 值。而现在，此文件夹中有两个文件引用，该更新哪个文件引用呢？ 此时，HEAD 就派上用场了。HEAD（所有字母大写）是 .git 文件夹根目录下的一个文件，指向 heads 文件夹中的头（英文为全部字母小写）文件。（请注意，“HEAD”实际上就是一个一直被命名为 HEAD 的文件，而“头”文件则没有特定的名称。） 头文件 HEAD 包含将分配为下一个提交对象的父 ID 的提交 ID。实际上，HEAD 标记的是 Git 当前在 DAG 上的位置。也就是说，可能有很多头，但始终只有一个 HEAD。

再回到图 8，提交 01 显示 HEAD 指向 master 头文件，进而指向 A1（也就是说，master 头文件包含提交对象 A1 的 SHA-1）。在提交 02 中，Git 不需要对 HEAD 文件执行任何操作，因为 HEAD 已经指向文件 master。提交 03 同上。不过，在“创建和签出新分支”步骤中，用户创建了一个分支，并通过选中“签出分支”复选框签出了分支文件。作为响应，Git 将 HEAD 更新为指向 feat_print_preview 头文件，而不是 master。（如果用户没有选中“签出分支”复选框，那么 HEAD 会继续指向 master。）

了解 HEAD 后，现在可以看到提交 04 不再需要 Git 做出任何决定： Git 只需检查 HEAD 的值，发现它指向的是 feat_print_preview 头文件。然后，便确定必须将 feat_print_preview 头文件中的 SHA-1 更新为包含 B1 的提交 ID。

在“签出分支”步骤中，用户访问了团队资源管理器的“分支”窗格，右键单击了“主分支”，然后选择了“签出”。作为响应，Git 签出提交 A3 的文件，并将 HEAD 文件更新为指向 master 头文件。

此时，应该非常清楚为什么 Git 中的分支操作如此高效快速： 新建分支可以归结为创建一个文本文件（头文件）和更新另一个文本文件 (HEAD)。切换分支只涉及更新一个文本文件 (HEAD)，造成的性能影响通常很小，因为工作目录中的文件是从存储库进行更新。