帶你一步一步了解Git的底層原理

作為當(dāng)前世界上最強(qiáng)大的代碼管理工具Git相信大家都很熟悉，但據(jù)我所知有很大一批人停留在clone、commit、pull、push.。.的階段，是不是對rebase心里沒底只敢用merge？

碰見版本回退就抓瞎？別問我怎么知道的，問就是：“我曾經(jīng)就是這樣啊～～”。

針對這些問題，今天我就將這幾年對Git的認(rèn)知和理解分享出來，盡可能的從本質(zhì)去講解Git，幫助你一步一步去了解Git的底層原理，相信讀完本篇文章你便可以換種姿態(tài)，更加風(fēng)騷得使用Git各種指令。

目錄

1. 基本概念

1.1 Git的優(yōu)勢

1.2 文件狀態(tài)

1.3 commit 節(jié)點

1.4 HEAD

1.5 遠(yuǎn)程倉庫

2. 分支

2.1 什么是分支？

3. 命令詳解

3.1 提交相關(guān)

3.2 分支相關(guān)

3.3 合并相關(guān)

3.4 回退相關(guān)

3.5 遠(yuǎn)程相關(guān)

1基本概念

1.1 Git的優(yōu)勢

Git是一個分布式代碼管理工具，在討論分布式之前避免不了提及一下什么是中央式代碼管理倉庫

中央式：所有的代碼保存在中央服務(wù)器，所以提交必須依賴網(wǎng)絡(luò)，并且每次提交都會帶入到中央倉庫，如果是協(xié)同開發(fā)可能頻繁觸發(fā)代碼合并，進(jìn)而增加提交的成本和代價。最典型的就是svn

分布式：可以在本地提交，不需要依賴網(wǎng)絡(luò)，并且會將每次提交自動備份到本地。每個開發(fā)者都可以把遠(yuǎn)程倉庫clone一份到本地，并會把提交歷史一并拿過來。代表就是Git

那Git相比于svn有什么優(yōu)勢呢？

打個比方：“巴拉巴拉寫了一大堆代碼，突然發(fā)現(xiàn)寫的有問題，我想回到一個小時之前”，對于這種情況Git的優(yōu)勢就很明顯了，因為commit的成本比較小并且本地會保存所有的提交記錄，隨時隨刻可以進(jìn)行回退。

在這并不是說svn的不能完成這種操作，只是Git的回退會顯得更加的優(yōu)雅。Git相比于中央式工具還有很多優(yōu)點，就不一一列舉了，感興趣的可自行了解。

1.2 文件狀態(tài)

在Git中文件大概分為三種狀態(tài)：已修改（modified）、已暫存（staged）、已提交（committed）

修改：Git可以感知到工作目錄中哪些文件被修改了，然后把修改的文件加入到modified區(qū)域

暫存：通過add命令將工作目錄中修改的文件提交到暫存區(qū)，等候被commit

提交：將暫存區(qū)文件commit至Git目錄中永久保存

1.3 commit節(jié)點

為了便于表述，本篇文章我會通過節(jié)點代稱commit提交

在Git中每次提交都會生成一個節(jié)點，而每個節(jié)點都會有一個哈希值作為唯一標(biāo)示，多次提交會形成一個線性節(jié)點鏈（不考慮merge的情況），如圖1-1

節(jié)點上方是通過 SHA1計算的哈希值

C2節(jié)點包含C1提交內(nèi)容，同樣C3節(jié)點包含C1、C2提交內(nèi)容

1.4 HEAD

HEAD是Git中非常重要的一個概念，你可以稱它為指針或者引用，它可以指向任意一個節(jié)點，并且指向的節(jié)點始終為當(dāng)前工作目錄，換句話說就是當(dāng)前工作目錄（也就是你所看到的代碼）就是HEAD指向的節(jié)點。

還以圖1-1舉例，如果HEAD指向C2那工作目錄對應(yīng)的就是C2節(jié)點。具體如何移動HEAD指向后面會講到，此處不要糾結(jié)。

同時HEAD也可以指向一個分支，間接指向分支所指向的節(jié)點。

1.5 遠(yuǎn)程倉庫

雖然Git會把代碼以及歷史保存在本地，但最終還是要提交到服務(wù)器上的遠(yuǎn)程倉庫。通過clone命令可以把遠(yuǎn)程倉庫的代碼下載到本地，同時也會將提交歷史、分支、HEAD等狀態(tài)一并同步到本地，但這些狀態(tài)并不會實時更新，需要手動從遠(yuǎn)程倉庫去拉取，至于何時拉、怎么拉后面章節(jié)會講到。

通過遠(yuǎn)程倉庫為中介，你可以和你的同事進(jìn)行協(xié)同開發(fā)，開發(fā)完新功能后可以申請?zhí)峤恢吝h(yuǎn)程倉庫，同時也可以從遠(yuǎn)程倉庫拉取你同事的代碼。

注意點

因為你和你的同事都會以遠(yuǎn)程倉庫的代碼為基準(zhǔn)，所以要時刻保證遠(yuǎn)程倉庫的代碼質(zhì)量，切記不要將未經(jīng)檢驗測試的代碼提交至遠(yuǎn)程倉庫

2分支

2.1 什么是分支？

分支也是Git中相當(dāng)重要的一個概念，當(dāng)一個分支指向一個節(jié)點時，當(dāng)前節(jié)點的內(nèi)容即是該分支的內(nèi)容，它的概念和HEAD非常接近同樣也可以視為指針或引用，不同的是分支可以存在多個，而HEAD只有一個。通常會根據(jù)功能或版本建立不同的分支。

那分支有什么用呢？

舉個例子：你們的 App 經(jīng)歷了千辛萬苦終于發(fā)布了v1.0版本，由于需求緊急v1.0上線之后便馬不停蹄的開始v1.1，正當(dāng)你開發(fā)的興起時，QA同學(xué)說用戶反饋了一些bug，需要修復(fù)然后重新發(fā)版，修復(fù)v1.0肯定要基于v1.0的代碼，可是你已經(jīng)開發(fā)了一部分v1.1了，此時怎么搞？

面對上面的問題通過引入分支概念便可優(yōu)雅的解決，如圖2-1

先看左邊示意圖，假設(shè)C2節(jié)點既是v1.0版本代碼，上線后在C2的基礎(chǔ)上新建一個分支ft-1.0

再看右邊示意圖，在v1.0上線后可在master分支開發(fā)v1.1內(nèi)容，收到QA同學(xué)反饋后提交v1.1代碼生成節(jié)點C3，隨后切換到ft-1.0分支做bug修復(fù)，修復(fù)完成后提交代碼生成節(jié)點C4，然后再切換到master分支并合并ft-1.0分支，到此我們就解決了上面提出的問題

除此之外利用分支還可以做很多事情，比如現(xiàn)在有一個需求不確定要不要上線，但是得先做，此時可以單獨創(chuàng)建一個分支開發(fā)該功能，等到啥時候需要上線直接合并到主分支即可。分支適用的場景很多就不一一列舉了。

注意點

當(dāng)在某個節(jié)點創(chuàng)建一個分支后，并不會把該節(jié)點對應(yīng)的代碼復(fù)制一份出來，只是將新分支指向該節(jié)點，因此可以很大程度減少空間上的開銷。一定要記著不管是HEAD還是分支它們都只是引用而已，量級非常輕

3命令詳解

3.1 提交相關(guān)

前面我們提到過，想要對代碼進(jìn)行提交必須得先加入到暫存區(qū)，Git中是通過命令 add 實現(xiàn)

添加某個文件到暫存區(qū)：

git add 文件路徑

添加所有文件到暫存區(qū)：

git add 。

同時Git也提供了撤銷工作區(qū)和暫存區(qū)命令

撤銷工作區(qū)改動：

git checkout -- 文件名

清空暫存區(qū)：

git reset HEAD 文件名

提交：

將改動文件加入到暫存區(qū)后就可以進(jìn)行提交了，提交后會生成一個新的提交節(jié)點，具體命令如下：

git commit -m “該節(jié)點的描述信息”

3.2 分支相關(guān)

創(chuàng)建分支

創(chuàng)建一個分支后該分支會與HEAD指向同一節(jié)點，說通俗點就是HEAD指向哪創(chuàng)建的新分支就指向哪，命令如下：

git branch 分支名

切換分支

當(dāng)切換分支后，默認(rèn)情況下HEAD會指向當(dāng)前分支，即HEAD間接指向當(dāng)前分支指向的節(jié)點

git checkout 分支名

同時也可以創(chuàng)建一個分支后立即切換，命令如下：

git checkout -b 分支名

刪除分支

為了保證倉庫分支的簡潔，當(dāng)某個分支完成了它的使命后應(yīng)該被刪除。比如前面所說的單獨開一個分支完成某個功能，當(dāng)這個功能被合并到主分支后應(yīng)該將這個分支及時刪除。

刪除命令如下：

git branch -d 分支名

3.3 合并相關(guān)

關(guān)于合并的命令是最難掌握同時也是最重要的。我們常用的合并命令大概有三個merge、rebase、cherry-pick

merge

merge是最常用的合并命令，它可以將某個分支或者某個節(jié)點的代碼合并至當(dāng)前分支。具體命令如下：

git merge 分支名/節(jié)點哈希值

如果需要合并的分支完全領(lǐng)先于當(dāng)前分支，如圖3-1所示

由于分支ft-1完全領(lǐng)先分支ft-2即ft-1完全包含ft-2，所以ft-2執(zhí)行了“git merge ft-1”后會觸發(fā)fast forward（快速合并），此時兩個分支指向同一節(jié)點，這是最理想的狀態(tài)。

但是實際開發(fā)中我們往往碰到是是下面這種情況：如圖3-2（左）

這種情況就不能直接合了，當(dāng)ft-2執(zhí)行了“git merge ft-1”后Git會將節(jié)點C3、C4合并隨后生成一個新節(jié)點C5，最后將ft-2指向C5 如圖3-2（右）

注意點：

如果C3、C4同時修改了同一個文件中的同一句代碼，這個時候合并會出錯，因為Git不知道該以哪個節(jié)點為標(biāo)準(zhǔn)，所以這個時候需要我們自己手動合并代碼

rebase

rebase也是一種合并指令，命令行如下：

git rebase 分支名/節(jié)點哈希值

與merge不同的是rebase合并看起來不會產(chǎn)生新的節(jié)點（實際上是會產(chǎn)生的，只是做了一次復(fù)制），而是將需要合并的節(jié)點直接累加 如圖3-3

當(dāng)左邊示意圖的ft-1.0執(zhí)行了git rebase master后會將C4節(jié)點復(fù)制一份到C3后面，也就是C4‘，C4與C4’相對應(yīng)，但是哈希值卻不一樣。

rebase相比于merge提交歷史更加線性、干凈，使并行的開發(fā)流程看起來像串行，更符合我們的直覺。既然rebase這么好用是不是可以拋棄merge了？其實也不是了，下面我羅列一些merge和rebase的優(yōu)缺點：

merge優(yōu)缺點：

優(yōu)點：每個節(jié)點都是嚴(yán)格按照時間排列。當(dāng)合并發(fā)生沖突時，只需要解決兩個分支所指向的節(jié)點的沖突即可

缺點：合并兩個分支時大概率會生成新的節(jié)點并分叉，久而久之提交歷史會變成一團(tuán)亂麻

rebase優(yōu)缺點：

優(yōu)點：會使提交歷史看起來更加線性、干凈

缺點：雖然提交看起來像是線性的，但并不是真正的按時間排序，比如圖3-3中，不管C4早于或者晚于C3提交它最終都會放在C3后面。并且當(dāng)合并發(fā)生沖突時，理論上來講有幾個節(jié)點rebase到目標(biāo)分支就可能處理幾次沖突

對于網(wǎng)絡(luò)上一些只用rebase的觀點，作者表示不太認(rèn)同，如果不同分支的合并使用rebase可能需要重復(fù)解決沖突，這樣就得不償失了。但如果是本地推到遠(yuǎn)程并對應(yīng)的是同一條分支可以優(yōu)先考慮rebase。所以我的觀點是 根據(jù)不同場景合理搭配使用merge和rebase，如果覺得都行那優(yōu)先使用rebase

cherry-pick

cherry-pick的合并不同于merge和rebase，它可以選擇某幾個節(jié)點進(jìn)行合并，如圖3-4

命令行：

git cherry-pick 節(jié)點哈希值

假設(shè)當(dāng)前分支是master，執(zhí)行了git cherry-pick C3（哈希值），C4（哈希值）命令后會直接將C3、C4節(jié)點抓過來放在后面，對應(yīng)C3‘和C4’

3.4 回退相關(guān)

分離HEAD

在默認(rèn)情況下HEAD是指向分支的，但也可以將HEAD從分支上取下來直接指向某個節(jié)點，此過程就是分離HEAD，具體命令如下：

git checkout 節(jié)點哈希值

//也可以直接脫離分支指向當(dāng)前節(jié)點

git checkout --detach

由于哈希值是一串很長很長的亂碼，在實際操作中使用哈希值分離HEAD很麻煩，所以Git也提供了HEAD基于某一特殊位置（分支/HEAD）直接指向前一個或前N個節(jié)點的命令，也即相對引用，如下：

//HEAD分離并指向前一個節(jié)點

git checkout 分支名/HEAD^

//HEAD分離并指向前N個節(jié)點

git checkout 分支名～N

將HEAD分離出來指向節(jié)點有什么用呢？舉個例子：如果開發(fā)過程發(fā)現(xiàn)之前的提交有問題，此時可以將HEAD指向?qū)?yīng)的節(jié)點，修改完畢后再提交，此時你肯定不希望再生成一個新的節(jié)點，而你只需在提交時加上--amend即可，具體命令如下：

git commit --amend

回退

回退場景在平時開發(fā)中還是比較常見的，比如你巴拉巴拉寫了一大堆代碼然后提交，后面發(fā)現(xiàn)寫的有問題，于是你想將代碼回到前一個提交，這種場景可以通過reset解決，具體命令如下：

//回退N個提交

git reset HEAD~N

reset和相對引用很像，區(qū)別是reset會使分支和HEAD一并回退。

3.5 遠(yuǎn)程相關(guān)

當(dāng)我們接觸一個新項目時，第一件事情肯定是要把它的代碼拿下來，在Git中可以通過clone從遠(yuǎn)程倉庫復(fù)制一份代碼到本地，具體命令如下：

git clone 倉庫地址

前面的章節(jié)我也有提到過，clone不僅僅是復(fù)制代碼，它還會把遠(yuǎn)程倉庫的引用（分支/HEAD）一并取下保存在本地，如圖3-5所示：

其中origin/master和origin/ft-1為遠(yuǎn)程倉庫的分支，而遠(yuǎn)程的這些引用狀態(tài)是不會實時更新到本地的，比如遠(yuǎn)程倉庫origin/master分支增加了一次提交，此時本地是感知不到的，所以本地的origin/master分支依舊指向C4節(jié)點。我們可以通過fetch命令來手動更新遠(yuǎn)程倉庫狀態(tài)

小提示：

并不是存在服務(wù)器上的才能稱作是遠(yuǎn)程倉庫，你也可以clone本地倉庫作為遠(yuǎn)程，當(dāng)然實際開發(fā)中我們不可能把本地倉庫當(dāng)作公有倉庫，說這個只是單純的幫助你更清晰的理解分布式

fetch

說的通俗一點，fetch命令就是一次下載操作，它會將遠(yuǎn)程新增加的節(jié)點以及引用（分支/HEAD）的狀態(tài)下載到本地，具體命令如下：

git fetch 遠(yuǎn)程倉庫地址/分支名

pull

pull命令可以從遠(yuǎn)程倉庫的某個引用拉取代碼，具體命令如下：

git pull 遠(yuǎn)程分支名

其實pull的本質(zhì)就是fetch+merge，首先更新遠(yuǎn)程倉庫所有狀態(tài)到本地，隨后再進(jìn)行合并。合并完成后本地分支會指向最新節(jié)點

另外pull命令也可以通過rebase進(jìn)行合并，具體命令如下：

git pull --rebase 遠(yuǎn)程分支名

push

push命令可以將本地提交推送至遠(yuǎn)程，具體命令如下：

git push 遠(yuǎn)程分支名

如果直接push可能會失敗，因為可能存在沖突，所以在push之前往往會先pull一下，如果存在沖突本地解決。push成功后本地的遠(yuǎn)程分支引用會更新，與本地分支指向同一節(jié)點。

綜上所述

不管是HEAD還是分支，它們都只是引用而已，引用+節(jié)點是 Git 構(gòu)成分布式的關(guān)鍵

merge相比于rebase有更明確的時間歷史，而rebase會使提交更加線性應(yīng)當(dāng)優(yōu)先使用

通過移動HEAD可以查看每個提交對應(yīng)的代碼

clone或fetch都會將遠(yuǎn)程倉庫的所有提交、引用保存在本地一份

pull的本質(zhì)其實就是fetch+merge，也可以加入--rebase通過rebase方式合并

原文標(biāo)題：Git 各指令的本質(zhì)，真是通俗易懂啊

文章出處：【微信公眾號：Linux愛好者】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。

責(zé)任編輯：haq