git图谱的认识

在项目团队中，每个人对于git分支的管理、代码的提交与合并，可能存在不同的操作方式，时不时会导致合并代码的时候出错，而需要重新追踪代码的合并过程，这时候可以通过git谱图来进行分析追溯，但是很多情况下却看不懂git谱图，随着分支数量的增加，提交次数的增加，已经其支线的繁多也增加了git图谱的复杂性，所以自己做了部分实验，以更好的理解并看懂git图谱。

实验步骤

一、从master分支中，拉取一个新的分支，分支名为：feature_20200826_品种档案

刚从master拉出新的分支的时候，可以看出，新的分支和master分支都在同一行上，这一行为master分支的最后一次提交。这时候git图谱没有产生支线。

二、在新的分支上commit了修改

此时可以看出，从新分支的角度上看，新分支与原master分支的提交信息已分别显示在两行提交记录上。此时还是没有出现支线，但是可以看出，新分支的提交，是从maser分支的蓝色的点上，往上新增一行。

三、切换分支到master

此时，我切换到了master上，则出现了一段的支线，可以看出，粉红色的线是maser分支，而从master分支上，引申出一条蓝色的支线，这条支线就是新分支的提交。

四、在master分支上merge新分支

此时可以看到，本地的maser分支与新分支又回到了同一行上，支线被合并消失了。

至此，我们可以得出第一次结论：

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

2、新的分支commit的差异（或同一分支，不同仓库commit的差异）产生了新的支线。新创建一个分支并提交修改后切换了到原分支，会产生一条新的支线。在刚刚创建完分支，并且提交改动的时候，支线并没有出现，只有提交改动后，切换分支，才产生新的支线。

3、不同分支的merge合并了支线（同一分支，不同仓库的merge，合并了支线）

备注：本次实验只实验了一个远程仓库、一个本地仓库，两个不同分支的情况，另外一个远程仓库、一个分支、两个本地仓库的情况暂时没有实验，这种情况相当于两个人同时在一个分支上进行代码开发，当两人提交的代码有分歧的时候，也是会产生支线，当两人的代码进行merge的时候，支线也会进行合并。