Git图谱的介绍

声明:本文参考自:参考一

           参考二

           参考三

           参考四

           参考五

1.什么是Git图谱?

  Git图谱常见于Git图形化客户端工具(包括SourceTree、Tortoise等)中,利用不同颜色的点、线结合时间轴按照一定规律,呈现项目的版本演进记录。

                                 

  这两张图片分别是SourceTree和TortoiseGit中的图谱,看起来大同小异,实际也是如此。下面的所有示例我都将结合SourceTree这一工具来加以说明。

  我们使用的Git协作方式如下图:

  

   一个origin远程仓库,不直接在上面修改代码,无数个本地仓库,分别与origin远程仓库同步。下面的说明都默认基于一个远程仓库。

  项目一说明:

  

   基于此,我们有可能得出下面的结论

  1.每一个点代表一次提交记录

  2.蓝色的那条线代表master分支

  是这样吗?

2.不同颜色的线到底代表什么?

  从图上我们可以看出,每一个点后面都有对应的commit message提交时间提交作者哈希值几个主要信息,这些信息都是一一对应的,所以,可以确定:每一个点代表一次提交记录。

  但是,蓝色的线代表master分支吗,或者说,一条线代表一个分支吗?我们再看下图:

  

   项目二说明:

  

  看出来了吗?同样只有一个分支,但是这个项目却衍生出了一条红色的线。所以,支线不一定代表分支,那支线为什么会出现呢?

 与项目一不同的是,这里有两个本地仓库,所以,可以推断出,应该是两个仓库的提交出现分歧时,才衍生了新的支线。这个时候,我想到了分布式版本控制系统这个词。在只有一种分支的情况下,有多少个本地仓库,就有可能衍生出多少条支线,从图谱上看到的,实际是项目的分布式进展情况。

  那么,支线跟分支就没有关系吗?看下图:

  

   项目三说明:

  

   看出来什么了吗?虽然支线不一定代表分支,但是,新创建一个分支必然会产生一条新的支线。但是,我们应该要知道,不是因为新创建分支产生了支线,而是,我们在分支上的改动与主线有分歧,才出现了新的支线。有一个细节是,在刚刚创建完分支,并且提交改动的时候,支线并没有出现,只有当切换分支,提交改动后,才产生新的支线。

  这样一来,上面的结论也许就不正确了,但是,我们创建分支的目的不就是让项目有一条新的支线走向吗,如果创建分支,不改动代码,那干嘛要创建分支?

3.关于主线

  

   

   

   项目四说明:

  

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

  蓝色支线代表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版本的高低表示该操作时间的先后

posted @   WK_BlogYard  阅读(4180)  评论(1编辑  收藏  举报
编辑推荐:
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
阅读排行:
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 清华大学推出第四讲使用 DeepSeek + DeepResearch 让科研像聊天一样简单!
· 实操Deepseek接入个人知识库
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
点击右上角即可分享
微信分享提示