Pro Git研读精选：分支介绍和分支合并

本文摘取自《Pro Git》第三章的第一节和第二节，由本人进行适当修改和删减。

何谓分支

为了理解 Git 分支的实现方式，我们需要回顾一下 Git 是如何储存数据的。Git 保存的不是文件差异或者变化量，而只是一系列文件快照。

在 Git 中提交时，会保存一个提交（commit）对象，该对象包含一个指向暂存内容快照的指针，包含本次提交的作者等相关附属信息，包含零个或多个指向该提交对象的父对象指针：首次提交是没有直接祖先的，普通提交有一个祖先，由两个或多个分支合并产生的提交则有多个祖先。

为直观起见，我们假设在工作目录中有三个文件，准备将它们暂存后提交(代码如下)。暂存操作会对每一个文件计算校验和（即第一章中提到的 SHA-1 哈希字串），然后把当前版本的文件快照保存到 Git 仓库中（Git 使用 blob 类型的对象存储这些快照），并将校验和加入暂存区域：

$ git add README test.rb LICENSE

$ git commit -m 'initial commit of my project'

 

当使用 git commit 新建一个提交对象前，Git 会先计算每一个子目录（本例中就是项目根目录）的校验和，然后在 Git 仓库中将这些目录保存为树（tree）对象。之后 Git 创建的提交对象，除了包含相关提交信息以外，还包含着指向这个树对象（项目根目录）的指针，如此它就可以在将来需要的时候，重现此次快照的内容了。

现在，Git 仓库中有五个对象：三个表示文件快照内容的 blob 对象（图3-1的3个红色方块）；一个记录着目录树内容及其中各个文件对应 blob 对象索引的 tree 对象（图3-1的蓝色方块）；以及一个包含指向 tree 对象（根目录）的索引和其他提交信息元数据的 commit 对象（图3-1的绿色方块）。概念上来说，仓库中的各个对象保存的数据和相互关系看起来如图 3-1 所示：

图  3-1.  单个提交对象在仓库中的数据结构

 

进行一些修改后再次提交，那么这次的提交对象会包含一个指向上次提交对象的指针（即下图中的 parent 对象）。两次提交后，仓库历史会变成图 3-2 的样子：最右边的为最新的提交，包含一个指向上次提交对象的指针。

 

图 3-2. 多个提交对象之间的链接关系

 

现在来谈分支。Git 中的分支，其实本质上仅仅是个指向 commit 对象的可变指针。Git 会使用 master 作为分支的默认名字。在若干次提交后，你其实已经有了一个指向最后一次提交对象的 master 分支，它在每次提交的时候都会自动向前移动。

图 3-3. 分支其实就是从某个提交对象往回看的历史

 

那么，Git 又是如何创建一个新的分支的呢？答案很简单，创建一个新的分支指针。比如新建一个 testing 分支，可以使用 git branch 命令:

$ git branch testing

 

这会在当前 commit 对象上新建一个分支指针（见图 3-4）。

图 3-4. 多个分支指向提交数据的历史

 

那么，Git 是如何知道你当前在哪个分支上工作的呢？其实答案也很简单，它保存着一个名为 HEAD 的特别指针。请注意它和你熟知的许多其他版本控制系统（比如 Subversion 或 CVS）里的 HEAD 概念大不相同。在 Git 中，它是一个指向你正在工作中的本地分支的指针（将 HEAD 想象为当前分支的别名。）。运行 git branch 命令，仅仅是建立了一个新的分支，但不会自动切换到这个分支中去，所以在这个例子中，我们依然还在 master 分支里工作（参考图 3-5）。

图 3-5. HEAD 指向当前所在的分支

要切换到其他分支，可以执行 git checkout 命令。我们现在转换到新建的 testing 分支：

$ git checkout testing

这样 HEAD 就指向了 testing 分支（见图3-6）。

图 3-6. HEAD 在你转换分支时指向新的分支

 

这样的实现方式会给我们带来什么好处呢？好吧，现在不妨再提交一次：

$ git commi