git分支图谱简介
声明：本文参考自：参考一
参考三
参考四
参考五
1.什么是Git图谱？
Git图谱常见于Git图形化客户端工具（包括SourceTree、Tortoise等）中，利用不同颜色的点、线结合时间轴按照一定规律，呈现项目的版本演进记录。
这两张图片分别是SourceTree和TortoiseGit中的图谱，看起来大同小异，实际也是如此。下面的所有示例我都将结合SourceTree这一工具来加以说明。
我们使用的Git协作方式如下图：
一个origin远程仓库，不直接在上面修改代码，无数个本地仓库，分别与origin远程仓库同步。下面的说明都默认基于一个远程仓库。
项目一说明：
基于此，我们有可能得出下面的结论
1.每一个点代表一次提交记录
2.蓝色的那条线代表master分支
是这样吗？
2.不同颜色的线到底代表什么？
从图上我们可以看出，每一个点后面都有对应的commit message，提交时间，提交作者和哈希值几个主要信息，这些信息都是一一对应的，所以，可以确定：每一个点代表一次提交记录。
但是，蓝色的线代表master分支吗，或者说，一条线代表一个分支吗？我们再看下图：
项目二说明：
看出来了吗？同样只有一个分支，但是这个项目却衍生出了一条红色的线。所以，支线不一定代表分支，那支线为什么会出现呢？
两个本地仓库，所以，可以推断出，应该是两个仓库的提交出现分歧时，才衍生了新的支线。这个时候，我想到了分布式版本控制系统这个词。在只有一种分支的情况下，有多少个本地仓库，就有可能衍生出多少条支线，从图谱上看到的，实际是项目的分布式进展情况。
那么，支线跟分支就没有关系吗？看下图：
项目三说明：
看出来什么了吗？虽然支线不一定代表分支，但是，新创建一个分支必然会产生一条新的支线。但是，我们应该要知道，不是因为新创建分支产生了支线，而是，我们在分支上的改动与主线有分歧，才出现了新的支线。有一个细节是，在刚刚创建完分支，并且提交改动的时候，支线并没有出现，只有当切换分支，提交改动后，才产生新的支线。
这样一来，上面的结论也许就不正确了，但是，我们创建分支的目的不就是让项目有一条新的支线走向吗，如果创建分支，不改动代码，那干嘛要创建分支？
3.关于主线
项目四说明：
上面三个图，是在当前没有未提交的改动的情况下，分别切换到local、dev和master 三个分支时候的图谱。那是不是就确定了.
蓝色支线代表dev分支
绿色支线代表local分支
红色支线代表master分支
当我进行了很多新的操作后的效果：
新的结论：
蓝色支线代表local分支
绿色支线代表master分支
红色支线代表local分支
黄色支线（哪儿冒出来的）代表dev分支
这里有一个变化条件就是多了一个本地仓库，实际开发中，经常是好几个人开发同一个项目，本地仓库也就相应的增加了，所以，每条颜色的支线不会固定代表某个分支，不同颜色的线可能代表同一个分支，这跟项目二的效果其实是一样的。
颜色虽然会变化，但有些东西却不会变化，不变的这些东西，就是规律，也正是看懂Git图谱的关键，也是这一节的主题——主线。
项目最早的一次提交与最近的一次提交连成的最长的直线就是主线，也是唯一的一条直线，它的走向也就是时间轴的走向。主线上衍生支线，支线上又会衍生出新的支线。
总结
综上所述，得出以下几点：
1.新的分支commit的差异，产生了新的支线
2.同一分支，不同仓库commit的差异，产生了新的支线
3.同一分支，不同仓库的merge，合并了支线
4.不同分支的merge合并了支线
如果你知道，Git每次提交操作保存的提交对象包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针（首次提交产生的提交对象没有父对象，普通提交操作产生的提交对象有一个父对象，而由多个分支合并产生的提交对象有多个父对象），也就理解，为什么会呈现出这样的图谱了。
在实际工作中，Git图谱的复杂导致我们几乎忽略了它的存在，况且我们开发时也并不需要它，但我们通过研究图谱，加深对Git基础设计的了解，还是非常有意义的。
4.idea git图解分析
compact references view 引用视图:
引用：
align references to left 将引用向左对齐
设置是否显示标签：
Show long Edges 显示长线:
Turn Intellisort On 打开intelli 排序
incase of merge show incoming commits first (directly below merge commit)
在合并的情况下，首先显示传入的提交 直接合并在下边
Trun IntelliSort On
打开intelli 排序:
默认排序：
默认排序按照时间线，不同分支提交节点交替分支数少，对应:
collapse linear branch and Expand linear branch
折叠的线性分支 和 扩展线性分支:
1.显示git分支图的命令是：git log --oneline --graph --all
1所示，表示dev1、dev2、dev3都从master分支切出并分别提交了2次
3.dev4也是从master分支切出兵提交了一次
2所示和图1相同的内容(git Fork软件)
图1
图2
3是在master分支上执行了git merge dev1,可以看出master分支已经前进到了和dev1分支一样的位置
注意：这里的每个分支的提交都没有产生冲突，我只是为了学习分支图，每个分支修改各自的文件，所以不会产生冲突
4可以很清楚的看到，master和dev1在同一个位置
图3
图4
- 在master分支上执行git merge dev2时如图5
- 可以看到dev1的两次提交都在主分支上(说明dev1已经合并到主分支了)
- dev2是从master分支上切出来的最后又合并到master分支上了
- 图6可以很清晰的看到图5所示的情况
图5
图6
- 在master分支上执行git merge dev3时如图7
- 可以看到dev2从master分支上切出后提交了2次，然后又被合并到master上，master3也是一样
图7
- 在dev3上切出一个dev3_1分支，然后做一次提交如图8所示
- master已经不是最左边的那调线了，每一行有一个commitID也对应一个commit提交信息，当然也有一个*，这三者是一一对应的
- 可以在第二行中看到master对应的事第二行的*，*对应的线是第二条即第二条显示master
- 可以看到从 7af413c (dev3) dev3第三次提交出切出了一个分支dev3_1
图8
- 删除dev1分支，记住一定要在master分支删除，因为master分支上已经合并了dev1如图9、图10
- 删除dev2如图11 ,删除dev3如图12
图9
图10
1、最左边一条线是你在IDE里面的工作分支，比如现在我的工作分支就是hello2，但是该线上不只是有你当前的工作分支，一个分支可能只有一个节点，这种情况下说明该分支上没有做任何更新记录，也可能有多个节点，每个节点表示一次更新记录，这些节点的颜色是相同的，不同的颜色代表不同的分支；同时，这个线条也是一个时间轴。沿着最左边一条线从上往下走，比如当前的分支是hello2分支，该分支的起源在Rev——>24那里，是从mytest分支上拉出来的一个分支，Rev——>26,34,35,36,37,39都是hello2分支的更新记录
选几个有代表性的节点来说：
Rev——>33是hello2分支和mytest分支做了一次merge，但是为什么hello2分支上没有出现一个小圆圈的节点呢，说明合并的时候有冲突，保留了hello2分支上的内容，把hello2分支上的内容更新到了mytest分支上，所以mytest分支上有一个红色的圆圈节点，换句话说，此次merge相当于mytest在Rev——>32的基础上做了一次更新，到Rev——>33了，而hello2还是原来的hello2，Rev版本的高低表示该操作时间的先后
