git提交结构图
git完整提交结构图如下所示 full commit graph
圆形代表commit对象，椭圆代表分支，三角形代表tree对象，长方形代表blob对象
因为commit对应的tree和blob对象已经深入研究过了，所以此处使用简化图来演示分支操作
simplified commit graph(缩减版-图左)
labeled commit graph(带标签版-图右)
git分支操作
分支代表了不同的支线任务条，使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线，从而并行执行不同任务。
分支是git的核心，也是git有别于其他版本控制软件的根本原因，git中鼓励多使用分支，对git而言分支的创建和切换也非常简单。
而在很多版本控制系统中，分支操作是一个略微低效的过程 -- 常常需要完全创建一个源代码目录的副本，对于大项目而言会耗费很多时间。
初始化项目
在demo目录下初始化git仓库，然后进行3次提交操作，每次新增一个文件进行提交。三次提交的结构图如下，其中master为缺省(默认)分支，初始化git仓库时即会创建一个master分支，并且让HEAD指向该分支。此时master分支指向了最新的commit对象。
创建分支
创建分支命令：git branch "name"
创建分支的本质就是新增一个指针文件，指向了当前所在分支的commit对象，该文件在.git/refs/heads目录中，创建一个分支dev，可以看到此时dev和master文件保存了同一个commit对象的hash值
创建分支后的结构图
切换分支
切换分支命令：git checkout "name"，切换分支的本质实际上做了两步操作
1.改变HEAD指针的指向，即修改.git/HEAD文件的内容，指向新分支
2.将新分支对应的commit对象所包含的所有内容检出到工作空间
切换分支后结构图的变化
分叉分支
在dev分支上修改版本3.txt文件内容，然后进行提交，切换回master分支，修改版本2.txt文件内容，然后进行提交。
此时master分支和dev分支就形成了分叉，分别指向了不同的新的commit对象
两次提交后的结构变化图如下
合并分支
合并分支命令：git merge "name"
如果我们想将dev分支内容合并到master，那么首先需要切换到master分支，然后执行git merge进行合并操作，合并后查看版本3.txt和版本2.txt文件内容是否都已改变。
合并分支后会新生成一个commit对象，该commit对象同时指向了两个commit父对象，而master指向了该commit。注意此时dev分支并没有移动，仍然是指向以前的commit对象。
合并分支后的结构图
fast-forward
fast-forward -- 特殊的合并，特点是不会产生新的commit对象，只是改变指针的指向内容。
如果创建了一个分支后，分支产生了新的提交记录，但是master分支一直没有做任何修改操作，此时如果要合并分支到master，只需要简单改变master的指向为最新的commit对象即可。
如图，我们在master分支指向的commit对象上新增加了dev分支，并且在dev分支上进行了一次提交，此时合并dev分支到master就是fast-forward合并，只需要将master指向7a45d对应的commit对象即可。
在我们上面的合并分支示例中，当我们切换到dev分支，然后将master合并到dev分支，此时也是fast-forward合并，可以看到dev分支直接指向了master指向的commit对象，而没有产生新的合并commit对象。
PS：在产生分叉的分支上进行合并时需要使用一定的算法，而git使用的合并算法为Three-way Merge。该算法需要参考两个分支共同的commit对象，加上分支的两个commit对象进行差异性比较。
分支总结
由于 Git 中的分支实际上仅是一个包含所指对象校验和(40 个字符长度 SHA-1 字串)的文件，所以创建和销毁一个分支就变得非常廉价和快速了。
这和大多数版本控制系统形成了鲜明对比，它们管理分支大多采取备份所有项目文件到特定目录的方式，所以根据项目文件数量和大小不同，可能花费的时间也会有相当大的差别，快则几秒，慢则数分钟。
而 Git 的实现与项目复杂度无关，它永远可以在几毫秒的时间内完成分支的创建和切换。同时，因为每次提交时都记录了祖先信息(译注：即parent对象)，将来要合并分支时，寻找恰当的合并基础(译注：即共同祖先)的工作其实已经自然而然地摆在那里了，所以实现起来非常容易。 Git 鼓励开发者频繁使用分支，正是因为有着这些特性作保障。
