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 引用视图:

　　引用：https://img-blog.csdnimg.cn/20200623175015252.gif

　　

 　  align references to left 将引用向左对齐

　   设置是否显示标签：https://img-blog.csdnimg.cn/20200623175508751.gif

　　

 　　Show long Edges 显示长线:https://img-blog.csdnimg.cn/20200623184034726.gif

　　

　　Turn Intellisort On 打开intelli 排序

　　incase of merge show incoming commits first (directly below merge commit)
　　在合并的情况下，首先显示传入的提交 直接合并在下边

　　Trun IntelliSort On

　　打开intelli 排序:https://img-blog.csdnimg.cn/20200623190327930.gif

　　

　　默认排序：

　　默认排序按照时间线，不同分支提交节点交替分支数少，对应:https://img-blog.csdnimg.cn/20200623192816620.gif

　　

 　 collapse linear branch and Expand linear branch

　折叠的线性分支 和 扩展线性分支:https://img-blog.csdnimg.cn/20200623194630693.gif

　

　1.显示git分支图的命令是：git log --oneline --graph --all

　2.图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

1. 在master分支上执行git merge dev2时如图5
2. 可以看到dev1的两次提交都在主分支上(说明dev1已经合并到主分支了)
3. dev2是从master分支上切出来的最后又合并到master分支上了
4. 图6可以很清晰的看到图5所示的情况

　　

 　　　　　　　　　　　　　　　　　　　　　　　　　　　　图5

　　

 　　　　　　　　　　　　　　　　　　　　图6

1. 在master分支上执行git merge dev3时如图7
2. 可以看到dev2从master分支上切出后提交了2次，然后又被合并到master上，master3也是一样

　　

 　　　　　　　　　　　　　　　　　　　　　　　　　　　　图7

1. 在dev3上切出一个dev3_1分支，然后做一次提交如图8所示
2. master已经不是最左边的那调线了，每一行有一个commitID也对应一个commit提交信息，当然也有一个*，这三者是一一对应的
3. 可以在第二行中看到master对应的事第二行的*，*对应的线是第二条即第二条显示master
4. 可以看到从 7af413c (dev3) dev3第三次提交出切出了一个分支dev3_1

　　

 　　　　　　　　　　　　　　　　　　　　　　　　　　　　图8

1. 删除dev1分支，记住一定要在master分支删除，因为master分支上已经合并了dev1如图9、图10
2. 删除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版本的高低表示该操作时间的先后