带你一步一步看懂Git图谱_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图谱的关键，也是这一节的主题——主线。

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

总结

综上所述，得出以下几点：

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

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

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