[[346349]]

本文轉載自微信公眾號「小鹿動畫學編程」，作者小鹿。轉載本文請聯系小鹿動畫學編程公眾號。   

最近不咋在狀態，一直沒有寫技術文。今天爬上來主要和大伙兒嘮嘮 GIT 的變基模式(rebase)。

第一次在團隊合作項目中用到和學習到變基模式，是老大教科書般手把手教我的，通過項目中的不斷運用，總結出一些自己的使用和看法。

GIT 本身對于一些初學者理解的不是這么好，對我個人來說，一開始一些基本概念在剛接觸的時候，并不能通透的理解，只有當將這些概念放到實踐形成自己的理解，才能知道這個概念原來是這個意思，以及這個命令是這個樣子的。

所以，小鹿盡可能的多畫圖，少廢話，便于對 GIT 理解不夠透徹的朋友能夠提供一些幫助。

1、什么是變基(rebase)

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

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

假如，我們的樓層蓋好了，共18層，需要多個裝修工去每一層進行裝修。我的裝修團隊一共有三個人，分別為A、B、C。

A 負責第一層，B 負責第二層，C 負責第三層。按照正常的邏輯，三個人誰提前裝修完自己的那一層，誰就要到第四層進行裝修。

但是有個問題就是，假如 B 第二層也裝修完畢，但是 B 不知道其他兩個人的最新進度，所以需要通過某種方式，把自己當前的進度更新到最新(B 應該知道下一步該裝修第幾層)，才能繼續在其他兩人的進度基礎上繼續裝修。

以上蓋樓的例子雖然不是太符合項目中團隊合作使用 GIT 變基，為了讓大伙兒先有個大體的印象。

2、為什么使用變基?

一般我們團隊合作使用 GIT 版本控制，每個人在自己分支上開發，最后負責人把每個人開發的分支 merge(合并) 到總分支上就可以了，又出了個變基模式，是干嘛的?

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

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

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

3、如何變基?

對于如何變基，這部分最重要的是需要去實踐、實踐、實踐。沒有實踐，看了也白看，記住我說的。

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

當 B 第二層蓋完的時候，它想要得知以下大家的開發進度，然后在大家進度的基礎上進行接下來的開發。

就猶如在項目中，我要提交我開發完的功能，但是我開發當前功能的時候，遠程倉庫中可能有別人已經提交過代碼了，導致了我本地倉庫和遠程倉庫代碼不一致。

想要在 push 代碼前達到與遠程倉庫代碼一致，我們需要 rebase(變基) 一下，命令如下：

1git pull base dev --rebase 

這個命令的相當于，B 直接到達了樓層的第五層進行裝修。而且我們的裝修記錄，也就是我們的開發主分支變的非常的清晰和明確，就是一條掛滿 commit 的分支線。

4、我玩壞了的變基

但是問題來了，GIT 變基模式前期剛使用的時候，被我多次玩壞，總結出了一些經驗。

當我每次提交最新代碼的時候，每次忘記 rebase，也就是每次沒有顧及到遠程的最新代碼，而是開發完功能，直接進行提交，導致線上的代碼出現分叉(其實又回到了原來的提交方式)。

很著急，該咋辦?老大出馬，一個頂倆，沒毛病。

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

1git cherry-pick <commit id> 

當你 pick 完之后，再重新進行 push 和 pr，分叉的分支就回到了原來的一條線上。是不是很 nice?

小結

Git 變基完全理解了之后，感覺不是特別難，但是前期剛接觸，確實很多不太明白的地方，導致玩壞了很多次。話說回來，不經歷風雨，怎么見彩虹呢?