開發十年，就只剩下這套架構體系了！ >>>   

今天來介紹下 git 的 rebase 命令。這個命令是我進入新公司之後才瞭解到的，以前還真的沒使用過，儘管我接觸 git 已經有 3 年了。

假如現在有個專案，它的 git 狀態是這樣的：

這是背景，接下來我們正式開始今天的內容。

分支合併

我們先在 master 分支的基礎上新建一個 dev 分支, 並做一個 commit：

> $(master) git checkout -b dev

這時候另外一個開發人員發現 master 上的程式碼有一個問題，對 master 的程式碼做了一個 fix，使得 master 的 head 向前推進了一步:

如果我們想將 master 的 Fix 改動應用到 dev 分支上，要如何做呢？

可以使用 merge，我們來試下：

$(dev) git merge master

merge 過後 dev 分支向前推進了一步。我們看下多出來的 commit 資訊是怎樣的

dev 上 多出來的這個 commit（綠色的那個節點）, 就是我們的 merge 資訊。

有時候我們並不想要 git 記錄這個 merge 資訊，因為讓 git 的歷史記錄變得很繁瑣，要如何做呢？可以使用 rebase ！

我們先回到 master 提交了 fix 之後的 git 狀態：

執行 rebase 命令：

$ (dev) git rebase master

這時候看下 git 狀態：

比較下 merge 和 rebase 之後的狀態圖，我們可以發現 masste 的 fix 被接到 dev 的後面，並且沒有多出一個 merge 資訊。這樣 commit 資訊是不是簡潔了很多？

commit 改寫

除了用在分支的合併上， rebase 命令還能幫你修改 commit 記錄。

我們讓 dev 分支再向前推進 3 步：

╰─$ git log

提交完這 3 個 commit 之後，我們發現這 3 個 commit 屬於同一個改動型別，完全沒必要分成 3 個 commit。

那要怎麼做呢？還是可以使用 rebase

$ (dev) git rebase -i HEAD~4

執行該命令 shell 會進入互動模式（-i）

根據提示，我們將文字做如下修改(將 pick 換成 s,至於為什麼要這樣寫，可以看 git 的提示)：

儲存並退出：

現在 git 又進入瞭如下狀態，只不過綠色的那個節點包含了 4 個 commit 資訊

commit 0a15d3549ee9ec61ddeb33916c452fab2ad9b991 (HEAD -> dev)

這時候再將 dev 合併進 master，commit 資訊都會簡潔很多，並且也有利於 review。

總結

rebase 是一個很神奇的工具，可以幫你做一些比較特別的改動。但要注意， rebase 是會隱藏你真實的修改記錄的，所以最後呈現出來的 git 歷史並不能表現你的真實操作，這點要注意。

• pick：保留該commit（縮寫:p）
• reword：保留該commit，但我需要修改該commit的註釋（縮寫:r）
• edit：保留該commit, 但我要停下來修改該提交(不僅僅修改註釋)（縮寫:e）
• squash：將該commit和前一個commit合併（縮寫:s）
• fixup：將該commit和前一個commit合併，但我不要保留該提交的註釋資訊（縮寫:f）
• exec：執行shell命令（縮寫:x）
• drop：我要丟棄該commit