Git 變基模式如何理解

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

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

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 變基模式如何理解問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。