带你一步一步看懂Git图谱

17,499 阅读5分钟

我在网上搜索了许多资料,都没有找到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. 一个开发者

上面三个图,是在当前没有未提交的改动的情况下,分别切换到localdevmaster 三个分支时候的图谱。那是不是就确定了

  • 蓝色支线代表dev分支
  • 绿色支线代表local分支
  • 红色支线代表master分支

以后的项目走向就很容易看明白了呢?

好吧,继续往下看,当我进行了很多新的操作后的效果:

dev2.png

local2.png

master2.png

新的结论:

  • 蓝色支线代表local分支
  • 绿色支线代表master分支
  • 红色支线代表local分支
  • 黄色支线(哪儿冒出来的)代表dev分支

这里有一个变化条件就是多了一个本地仓库,实际开发中,经常是好几个人开发同一个项目,本地仓库也就相应的增加了,所以,每条颜色的支线不会固定代表某个分支,不同颜色的线可能代表同一个分支,这跟项目二的效果其实是一样的。

颜色虽然会变化,但有些东西却不会变化,不变的这些东西,就是规律,也正是看懂Git图谱的关键,也是这一节的主题——主线

项目最早的一次提交与最近的一次提交连成的最长的直线就是主线,也是唯一的一条直线,它的走向也就是时间轴的走向。主线上衍生支线,支线上又会衍生出新的支线。

总结

综上所述,得出以下几点:

  1. 新的分支commit的差异,产生了新的支线
  2. 同一分支,不同仓库commit的差异,产生了新的支线
  3. 同一分支,不同仓库的merge,合并了支线
  4. 不同分支的merge合并了支线

如果你知道,Git每次提交操作保存的提交对象包含了作者的姓名和邮箱、提交时输入的信息以及指向它的父对象的指针(首次提交产生的提交对象没有父对象,普通提交操作产生的提交对象有一个父对象,而由多个分支合并产生的提交对象有多个父对象),也就理解,为什么会呈现出这样的图谱了。

在实际工作中,Git图谱的复杂导致我们几乎忽略了它的存在,况且我们开发时也并不需要它,但我们通过研究图谱,加深对Git基础设计的了解,还是非常有意义的。

个人经验有限,文章仅供分享学习,错误疏漏之处,欢迎指正