带你一步一步看懂Git图谱
我在网上搜索了许多资料，都没有找到Git图谱的相关说明。无奈，只好自己分析整理了一些笔记，希望能够帮助大家看懂Git图谱。
什么是Git图谱？
Git图谱常见于Git图形化客户端工具（包括SourceTree、Tortoise等）中，利用不同颜色的点、线结合时间轴按照一定规律，呈现项目的版本演进记录。
SourceTree中的Git图谱
TortoiseGit中的Graph
这两张图片分别是SourceTree和TortoiseGit中的图谱，看起来大同小异，实际也是如此。下面的所有示例我都将结合SourceTree这一工具来加以说明，有需要的同学可以到SourceTree官网下载。
先看懂一点点
其实，个人觉得，大部分同学并不是真的看不懂Git图谱，只是感觉上面的图太过复杂而已！如果是这样一个图，就没有人会看不懂了。
某个项目
虽然这个项目很简单，但我们还是要明确一下，我们使用的Git协作方式如下图：
repository.png
一个origin远程仓库，不直接在上面修改代码，无数个本地仓库，分别与origin远程仓库同步。下面的说明都默认基于一个远程仓库。
项目一说明：
1. 一个`master`分支
2. 一个本地仓库
3. 一个开发者
基于此，我们有可能得出下面的结论
- 每一个点代表一次提交记录
- 蓝色的那条线代表master分支
是这样吗？
不同颜色的线到底代表什么？
从图上我们可以看出，每一个点后面都有对应的commit message，提交时间，提交作者和哈希值几个主要信息，这些信息都是一一对应的，所以，可以确定：每一个点代表一次提交记录。
但是，蓝色的线代表master分支吗，或者说，一条线代表一个分支吗？我们再看下图：
只有一个 分支的项目
项目二说明：
1. 一个`master`分支
2. 两个本地仓库
3. 一个开发者
看出来了吗？同样只有一个分支，但是这个项目却衍生出了一条红色的线。所以，支线不一定代表分支，那支线为什么会出现呢？
与项目一不同的是，这里有两个本地仓库，所以，可以推断出，应该是两个仓库的提交出现分歧时，才衍生了新的支线。这个时候，我想到了分布式版本控制系统这个词。在只有一种分支的情况下，有多少个本地仓库，就有可能衍生出多少条支线，从图谱上看到的，实际是项目的分布式进展情况。
那么，支线跟分支就没有关系吗？看下图：
1.png
项目三说明：
1. 两个分支 `local`和`master`
2. 一个本地仓库
3. 一个开发者
看出来什么了吗？虽然支线不一定代表分支，但是，新创建一个分支必然会产生一条新的支线。但是，我们应该要知道，不是因为新创建分支产生了支线，而是，我们在分支上的改动与主线有分歧，才出现了新的支线。有一个细节是，在刚刚创建完分支，并且提交改动的时候，支线并没有出现，只有当切换分支，提交改动后，才产生新的支线。
这样一来，上面的结论也许就不正确了，但是，我们创建分支的目的不就是让项目有一条新的支线走向吗，如果创建分支，不改动代码，那干嘛要创建分支？
关于主线
再看下面的图
local.png
dev.png
master.png
项目四说明：
1. 三个分支 `local`、`dev`和`master`
2. 一个本地仓库
3. 一个开发者
上面三个图，是在当前没有未提交的改动的情况下，分别切换到local、dev和master 三个分支时候的图谱。那是不是就确定了
- 蓝色支线代表
dev分支 - 绿色支线代表
local分支 - 红色支线代表
master分支
以后的项目走向就很容易看明白了呢？
好吧，继续往下看，当我进行了很多新的操作后的效果：
dev2.png
local2.png
master2.png
新的结论：
- 蓝色支线代表
local分支 - 绿色支线代表
master分支 - 红色支线代表
local分支 - 黄色支线（哪儿冒出来的）代表
dev分支
这里有一个变化条件就是多了一个本地仓库，实际开发中，经常是好几个人开发同一个项目，本地仓库也就相应的增加了，所以，每条颜色的支线不会固定代表某个分支，不同颜色的线可能代表同一个分支，这跟项目二的效果其实是一样的。
颜色虽然会变化，但有些东西却不会变化，不变的这些东西，就是规律，也正是看懂Git图谱的关键，也是这一节的主题——主线。
项目最早的一次提交与最近的一次提交连成的最长的直线就是主线，也是唯一的一条直线，它的走向也就是时间轴的走向。主线上衍生支线，支线上又会衍生出新的支线。
总结
综上所述，得出以下几点：
- 新的分支
commit的差异，产生了新的支线 - 同一分支，不同仓库
commit的差异，产生了新的支线 - 同一分支，不同仓库的
merge，合并了支线 - 不同分支的
merge合并了支线
如果你知道，Git每次提交操作保存的提交对象包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针（首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象，而由多个分支合并产生的提交对象有多个父对象），也就理解，为什么会呈现出这样的图谱了。
在实际工作中，Git图谱的复杂导致我们几乎忽略了它的存在，况且我们开发时也并不需要它，但我们通过研究图谱，加深对Git基础设计的了解，还是非常有意义的。
个人经验有限，文章仅供分享学习，错误疏漏之处，欢迎指正
