Git圖譜的介紹

聲明：本文參考自：參考一

　　　　　　　　   參考二

　　　　　　　　   參考三

　　　　　　　　   參考四

　　　　　　　　   參考五

1.什么是Git圖譜？

　　Git圖譜常見於Git圖形化客戶端工具（包括SourceTree、Tortoise等）中，利用不同顏色的點、線結合時間軸按照一定規律，呈現項目的版本演進記錄。

　　                               

　　這兩張圖片分別是SourceTree和TortoiseGit中的圖譜，看起來大同小異，實際也是如此。下面的所有示例我都將結合SourceTree這一工具來加以說明。

　　我們使用的Git協作方式如下圖：

　　

 　　一個origin遠程倉庫，不直接在上面修改代碼，無數個本地倉庫，分別與origin遠程倉庫同步。下面的說明都默認基於一個遠程倉庫。

　　項目一說明：

　　

 　 基於此，我們有可能得出下面的結論

　　1.每一個點代表一次提交記錄

　　2.藍色的那條線代表master分支

　　是這樣嗎？

2.不同顏色的線到底代表什么？

　　從圖上我們可以看出，每一個點后面都有對應的commit message，提交時間，提交作者和哈希值幾個主要信息，這些信息都是一一對應的，所以，可以確定：每一個點代表一次提交記錄。

　　但是，藍色的線代表master分支嗎，或者說，一條線代表一個分支嗎？我們再看下圖：

　　

 　　項目二說明：

　　

 　看出來了嗎？同樣只有一個分支，但是這個項目卻衍生出了一條紅色的線。所以，支線不一定代表分支，那支線為什么會出現呢？

　與項目一不同的是，這里有兩個本地倉庫，所以，可以推斷出，應該是兩個倉庫的提交出現分歧時，才衍生了新的支線。這個時候，我想到了分布式版本控制系統這個詞。在只有一種分支的情況下，有多少個本地倉庫，就有可能衍生出多少條支線，從圖譜上看到的，實際是項目的分布式進展情況。

　　那么，支線跟分支就沒有關系嗎？看下圖：

　　

 　　項目三說明：

　　

 　　看出來什么了嗎？雖然支線不一定代表分支，但是，新創建一個分支必然會產生一條新的支線。但是，我們應該要知道，不是因為新創建分支產生了支線，而是，我們在分支上的改動與主線有分歧，才出現了新的支線。有一個細節是，在剛剛創建完分支，並且提交改動的時候，支線並沒有出現，只有當切換分支，提交改動后，才產生新的支線。

　　這樣一來，上面的結論也許就不正確了，但是，我們創建分支的目的不就是讓項目有一條新的支線走向嗎，如果創建分支，不改動代碼，那干嘛要創建分支？

3.關於主線

　　

 　　

 　　

 　　項目四說明：

　　

 　上面三個圖，是在當前沒有未提交的改動的情況下，分別切換到local、dev和master 三個分支時候的圖譜。那是不是就確定了.

　　藍色支線代表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版本的高低表示該操作時間的先后