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基础设计的了解,还是非常有意义的。
转自:带你一步一步看懂Git图谱
https://blog.51cto.com/u_15668812/5349220