[[346349]]

本文轉(zhuǎn)載自微信公眾號(hào)「小鹿動(dòng)畫(huà)學(xué)編程」，作者小鹿。轉(zhuǎn)載本文請(qǐng)聯(lián)系小鹿動(dòng)畫(huà)學(xué)編程公眾號(hào)。   

最近不咋在狀態(tài)，一直沒(méi)有寫(xiě)技術(shù)文。今天爬上來(lái)主要和大伙兒嘮嘮 GIT 的變基模式(rebase)。

第一次在團(tuán)隊(duì)合作項(xiàng)目中用到和學(xué)習(xí)到變基模式，是老大教科書(shū)般手把手教我的，通過(guò)項(xiàng)目中的不斷運(yùn)用，總結(jié)出一些自己的使用和看法。

GIT 本身對(duì)于一些初學(xué)者理解的不是這么好，對(duì)我個(gè)人來(lái)說(shuō)，一開(kāi)始一些基本概念在剛接觸的時(shí)候，并不能通透的理解，只有當(dāng)將這些概念放到實(shí)踐形成自己的理解，才能知道這個(gè)概念原來(lái)是這個(gè)意思，以及這個(gè)命令是這個(gè)樣子的。

所以，小鹿盡可能的多畫(huà)圖，少?gòu)U話，便于對(duì) GIT 理解不夠透徹的朋友能夠提供一些幫助。

1、什么是變基(rebase)

變基，我們可以理解為基低的意思。就像蓋樓一樣，一層層的向上蓋，最下面是地基，我們把蓋的每一層稱為基。

(為了更好的理解，就拿上述蓋樓為例)

假如，我們的樓層蓋好了，共18層，需要多個(gè)裝修工去每一層進(jìn)行裝修。我的裝修團(tuán)隊(duì)一共有三個(gè)人，分別為A、B、C。

A 負(fù)責(zé)第一層，B 負(fù)責(zé)第二層，C 負(fù)責(zé)第三層。按照正常的邏輯，三個(gè)人誰(shuí)提前裝修完自己的那一層，誰(shuí)就要到第四層進(jìn)行裝修。

但是有個(gè)問(wèn)題就是，假如 B 第二層也裝修完畢，但是 B 不知道其他兩個(gè)人的最新進(jìn)度，所以需要通過(guò)某種方式，把自己當(dāng)前的進(jìn)度更新到最新(B 應(yīng)該知道下一步該裝修第幾層)，才能繼續(xù)在其他兩人的進(jìn)度基礎(chǔ)上繼續(xù)裝修。

以上蓋樓的例子雖然不是太符合項(xiàng)目中團(tuán)隊(duì)合作使用 GIT 變基，為了讓大伙兒先有個(gè)大體的印象。

2、為什么使用變基?

一般我們團(tuán)隊(duì)合作使用 GIT 版本控制，每個(gè)人在自己分支上開(kāi)發(fā)，最后負(fù)責(zé)人把每個(gè)人開(kāi)發(fā)的分支 merge(合并) 到總分支上就可以了，又出了個(gè)變基模式，是干嘛的?

其一，項(xiàng)目變大了，團(tuán)隊(duì)的人員變多了，提交的分支越來(lái)越多，而且每個(gè)人 commit 之后都要合并到主分支，整個(gè) git 分支圖看起來(lái)爛七八糟，不利于維護(hù)和管理。(如上圖所示)

其二，項(xiàng)目中充斥著各種各樣的 commit ，如果有一天，出現(xiàn)了緊急的事件，需要回滾代碼，發(fā)現(xiàn)這大量的 commit 需要一條條的看，讓你看到懷疑人生。

以上兩個(gè)理由完全可以讓我放棄傳統(tǒng)的提交合并，使用變基模式提交的代碼就顯的格外的清晰。(如下圖)

3、如何變基?

對(duì)于如何變基，這部分最重要的是需要去實(shí)踐、實(shí)踐、實(shí)踐。沒(méi)有實(shí)踐，看了也白看，記住我說(shuō)的。

變基模式，用到了以下幾個(gè)常用命令，還是以上述的蓋樓為例。

當(dāng) B 第二層蓋完的時(shí)候，它想要得知以下大家的開(kāi)發(fā)進(jìn)度，然后在大家進(jìn)度的基礎(chǔ)上進(jìn)行接下來(lái)的開(kāi)發(fā)。

就猶如在項(xiàng)目中，我要提交我開(kāi)發(fā)完的功能，但是我開(kāi)發(fā)當(dāng)前功能的時(shí)候，遠(yuǎn)程倉(cāng)庫(kù)中可能有別人已經(jīng)提交過(guò)代碼了，導(dǎo)致了我本地倉(cāng)庫(kù)和遠(yuǎn)程倉(cāng)庫(kù)代碼不一致。

想要在 push 代碼前達(dá)到與遠(yuǎn)程倉(cāng)庫(kù)代碼一致，我們需要 rebase(變基) 一下，命令如下：

1git pull base dev --rebase 

這個(gè)命令的相當(dāng)于，B 直接到達(dá)了樓層的第五層進(jìn)行裝修。而且我們的裝修記錄，也就是我們的開(kāi)發(fā)主分支變的非常的清晰和明確，就是一條掛滿 commit 的分支線。

4、我玩壞了的變基

但是問(wèn)題來(lái)了，GIT 變基模式前期剛使用的時(shí)候，被我多次玩壞，總結(jié)出了一些經(jīng)驗(yàn)。

當(dāng)我每次提交最新代碼的時(shí)候，每次忘記 rebase，也就是每次沒(méi)有顧及到遠(yuǎn)程的最新代碼，而是開(kāi)發(fā)完功能，直接進(jìn)行提交，導(dǎo)致線上的代碼出現(xiàn)分叉(其實(shí)又回到了原來(lái)的提交方式)。

很著急，該咋辦?老大出馬，一個(gè)頂倆，沒(méi)毛病。

使用回滾和 pick 的方式，讓主分支不再出現(xiàn)分叉。所謂的 pick 是使用 cherry-pick 命令將 commit 的提交重新掛在到你想要掛載的分支上。

1git cherry-pick <commit id> 

當(dāng)你 pick 完之后，再重新進(jìn)行 push 和 pr，分叉的分支就回到了原來(lái)的一條線上。是不是很 nice?

小結(jié)

Git 變基完全理解了之后，感覺(jué)不是特別難，但是前期剛接觸，確實(shí)很多不太明白的地方，導(dǎo)致玩壞了很多次。話說(shuō)回來(lái)，不經(jīng)歷風(fēng)雨，怎么見(jiàn)彩虹呢?