git rebase 使用總結

今天來介紹下 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（縮寫:d）