徹底搞懂 Git-Rebase

來源：http://jartto.wang/2018/12/11/git-rebase/?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

使用 Git 已經好幾年了，卻始終只是熟悉一些常用的操作。對於 Git Rebase 卻很少用到，直到這一次，不得不用。

一、起因

上線構建的過程中掃了一眼程式碼變更，突然發現，commit 提交竟然多達 62 次。我們來看看都提交了什麼東西：

這裡我們先不說 git 提交規範，就單純這麼多次無用的 commit 就很讓人不舒服。可能很多人覺得無所謂，無非是多了一些提交紀錄。

然而，並非如此，你可能聽過破窗效應，程式設計也是如此！

二、導致問題

1.不利於程式碼 review
設想一下，你要做 code review ，結果一個很小的功能，提交了 60 多次，會不會有一些崩潰？

2.會造成分支汙染
你的專案充滿了無用的 commit 紀錄，如果有一天線上出現了緊急問題，你需要回滾程式碼，卻發現海量的 commit 需要一條條來看。

遵循專案規範才能提高團隊協作效率，而不是隨心所欲。

三、Rebase 場景一：如何合併多次提交紀錄？

基於上面所說問題，我們不難想到：每一次功能開發， 對多個 commit 進行合併處理。

這時候就需要用到 git rebase 了。這個命令沒有太難，不常用可能源於不熟悉，所以我們來通過示例學習一下。

1.我們來合併最近的 4 次提交紀錄，執行：

2.這時候，會自動進入 vi 編輯模式：

有幾個命令需要注意一下：

• p, pick = use commit

• r, reword = use commit, but edit the commit message

• e, edit = use commit, but stop for amending

• s, squash = use commit, but meld into previous commit

• f, fixup = like “squash”, but discard this commit’s log message

• x, exec = run command (the rest of the line) using shell

• d, drop = remove commit

按照如上命令來修改你的提交紀錄：

3.如果儲存的時候，你碰到了這個錯誤：

注意不要合併先前提交的東西，也就是已經提交遠端分支的紀錄。

4.如果你異常退出了 vi 視窗，不要緊張：

這時候會一直處在這個編輯的模式裡，我們可以回去繼續編輯，修改完儲存一下：

5.檢視結果

三次提交合併成了一次，減少了無用的提交資訊。

四、Rebase 場景二：分支合併

1.我們先從 master 分支切出一個 dev 分支，進行開發：

2.這時候，你的同事完成了一次 hotfix，併合併入了 master 分支，此時 master 已經領先於你的 feature1 分支了：

3.恰巧，我們想要同步 master 分支的改動，首先想到了 merge，執行：

圖中綠色的點就是我們合併之後的結果，執行：

就會在記錄裡發現一些 merge 的資訊，但是我們覺得這樣汙染了 commit 記錄，想要保持一份乾淨的 commit，怎麼辦呢？這時候，git rebase 就派上用場了。

4.讓我們來試試 git rebase ，先回退到同事 hotfix 後合併 master 的步驟：

5.使用 rebase 後來看看結果：

這裡補充一點：rebase 做了什麼操作呢？

• 首先，git 會把 feature1 分支裡面的每個 commit 取消掉；

• 其次，把上面的操作臨時儲存成 patch 檔案，存在 .git/rebase 目錄下

• 然後，把 feature1 分支更新到最新的 master 分支；

• 最後，把上面儲存的 patch 檔案應用到 feature1 分支上；

從 commit 記錄我們可以看出來，feature1 分支是基於 hotfix 合併後的 master ，自然而然的成為了最領先的分支，而且沒有 merge 的 commit 記錄，是不是感覺很舒服了。

6.在 rebase 的過程中，也許會出現衝突 conflict。在這種情況，git 會停止 rebase 並會讓你去解決衝突。在解決完衝突後，用 git add 命令去更新這些內容。

注意，你無需執行 git-commit，只要執行 continue

這樣 git 會繼續應用餘下的 patch 補丁檔案。

7.在任何時候，我們都可以用 --abort 引數來終止 rebase 的行動，並且分支會回到 rebase 開始前的狀態。

五、更多 Rebase 的使用場景

git-rebase 存在的價值是：對一個分支做「變基」操作。

1.當我們在一個過時的分支上面開發的時候，執行 rebase 以此同步 master 分支最新變動；
2.假如我們要啟動一個放置了很久的並行工作，現在有時間來繼續這件事情，很顯然這個分支已經落後了。這時候需要在最新的基準上面開始工作，所以 rebase 是最合適的選擇。

六、為什麼會是危險操作？

根據上文來看，git-rebase 很完美，解決了我們的兩個問題：
1.合併 commit 記錄，保持分支整潔；
2.相比 merge 來說會減少分支合併的記錄；

如果你提交了程式碼到遠端，提交前是這樣的：

提交後遠端分支變成了這樣：

而此時你的同事也在 feature1 上開發，他的分支依然還是：

那麼當他 pull 遠端 master 的時候，就會有丟失提交紀錄。這就是為什麼我們經常聽到有人說 git rebase 是一個危險命令，因為它改變了歷史，我們應該謹慎使用。

除非你可以肯定該 feature1 分支只有你自己使用，否則請謹慎操作。

結論：只要你的分支上需要 rebase 的所有 commits 歷史還沒有被 push 過，就可以安全地使用 git-rebase來操作。

七、參考：

• rebase

• git-rebase 使用總結

• git 中的 rebase操作

• git-rebase vs git-merge 詳解

  ·END·

 近期熱文：

• 致敬| 她永遠地離開了，但我們依然每天收益於您的偉大發明！

• 在生產中使用Java 11：需要了解的重要事項

• 如何在到處是“雷”的系統中「明哲保身」？這是第一招

• 可能是最全面的G1學習筆記

• Spring Cloud Stream消費失敗後的處理策略（四）：重新入隊（RabbitMQ）

• 想通關「限流」？只要這一篇

• 面試題：如何求根號2

• Spring Cloud Stream消費失敗後的處理策略（三）：使用DLQ佇列（RabbitMQ）
  

點選“閱讀原文”，看本號其他精彩內容