Git 變基模式如何理解，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

創(chuàng)新互聯(lián)長期為上1000家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為圍場(chǎng)企業(yè)提供專業(yè)的成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站，圍場(chǎng)網(wǎng)站改版等技術(shù)服務(wù)。擁有10余年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

今天主要和大伙兒嘮嘮 GIT 的變基模式(rebase)。

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

1、什么是變基(rebase)

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

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

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

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

但是有個(gè)問題就是，假如 B 第二層也裝修完畢，但是 B 不知道其他兩個(gè)人的最新進(jìn)度，所以需要通過某種方式，把自己當(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è)人在自己分支上開發(fā)，最后負(fù)責(zé)人把每個(gè)人開發(fā)的分支 merge(合并)  到總分支上就可以了，又出了個(gè)變基模式，是干嘛的?

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

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

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

3、如何變基?

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

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

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

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

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

1git pull base dev --rebase

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

4、我玩壞了的變基

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

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

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

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

1git cherry-pick 

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

關(guān)于Git 變基模式如何理解問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。