一、前言

對于git rebase 一直不太了解,這幾天想著提高下git提交質量,就發現了這個好用的指令,順便記錄一下,好加深記憶

貼出官方文檔以便大家進一步學習 Git

二、rebase是作用

• rebase 官方解釋為變基,可以理解為移動你的分支根節點,維護一個更好的提交記錄。rebase把你當前最新分支與其他分支合并時候,會把其他分支的提交記錄放在我們當前分支時間線最開始的位置。也就是說,會把我們的提交記錄整合在公共分支的后面。
• 簡單來講,合并本地其他分支 為了不產生多余的分叉,及合并記錄時可以使用rebase。
• 接下來我們看一下rebase有哪些應用場景及使用技巧與merge的差異。

三、rebase與merge的差異

• rebase 會把你當前分支的 commit 放到公共分支的最后面,所以叫變基。就好像你從公共分支又重新拉出來這個分支一樣。
• merge 會把公共分支和你當前的 commit 合并在一起，形成一個新的 commit 提交。

四、應用場景

• 你剛入公司，技術leader讓你以 master 分支為基礎,拉出一個分支進行開發需求。此時 master 分支提交記錄為 a、b。你在 dev 分支分別 commit 了2次記錄為 e、f ,有其他同事在 master 分支提交了兩次記錄為 c、d 這個時候你要合并master分支代碼。

• 當前分支狀態節點如下圖所示:

五、使用git merge 進行合并操作

5.1、結論

1. 如上圖所示 merge 會把兩個分支合并在一起，形成一個新的 commit 提交記錄。
2. 我們發現 coomit 提交記錄是把合并的分支記錄放到我們當前dev分支記錄的后面。
3. 并且coomit 提交記錄會產生分叉。

七、使用git rebase 進行合并操作

  $ git rebase master  // 合并master分支代碼$ git log --graph --oneline // 查看log點線圖// 符號解釋:* 表示一個commit， 注意不要管*在哪一條主線上 | 表示分支前進 / 表示分叉 \ 表示合入

7.1、結論

1. 首先，我們發現目前 dev 分支上面的提交記錄為 abcdef 并沒有像 merge 一樣產生新的提交記錄
2. 其次 rebase master 分支到 dev 分支, dev 分支的歷史記錄會添加在 master 分支的后面。
3. 如圖所示，歷史記錄成一條線,非常整潔,最后并沒有像使 merge 一樣提交記錄產生分叉。

八、rebase的使用業務場景

• 認識到了rebase,讓我們來看看有哪些實戰場景可以參考使用。

8.1 場景一

• 經典場景,優化本地提交記錄,使其減少分叉。
• 和上面👆那個經典案例一樣,這里就不做重復描述了😁

8.2 場景二

• 連續性沖突
• 此時你從master分支拉出一個dev分支來對以v1版本為基礎a功能進行需求更改，由于項目經理分功能時,讓你的同事也對master分支中的a功能中的某個公共頁面a也進行了整改,過一會你同事改完,提交x版本并合并push到了master遠程分支上面。此時我們在dev分支完成一次開發提交了v2版本,產品經理過來說,需求有變更,要再做修改,然后我們又以v2的基礎上在做修改,并提交為v3版本。過一會測試又提了一個需求建議。我們接著以當前dev分支v3版本為基礎做好了整改并commit一個v4版本。到此我們本地假設對頁面a修改了三次。同事修改了一次,并push到了遠程master上面。那么我們對master分支進行合并到時候就會產生沖突。
• 簡單來講就是。遠程分支 master 對文件a進行了1次 commit ，而別的分支dev對文件A進行了3次commit，但是本地分支dev提交的n次 commit都與master分支的1次commit有沖突，

8.2.1 使用 git rebase 解決沖突

$ git fetch  // 更新本地存儲的遠程倉庫的分支引用
$ git rebase origin/master // 拉去遠程分支master中的代碼與當前分支合并且變基
// 此時我們會產生第一次沖突,為當前dev分支版本v2中的a頁面與遠程分支master中的a頁面沖突。解決后,根據提示進行 
$ git add .
$ git rebase continue // 繼續進行合并
// 此時我們會產生第二次沖突,為當前dev分支版本v3中的a頁面與遠程分支master中的a頁面沖突。解決后,根據提示進行 
$ git add .
$ git rebase continue // 繼續進行合并
// 此時我們會產生第三次沖突,為當前dev分支版本v4中的a頁面與遠程分支master中的a頁面沖突。解決后,根據提示進行 
$ git add .
$ git rebase continue // 繼續進行合并
// 至此我們使用 rebase 變基完成 可以根據產品需求push到遠程dev分支
$ git log --graph --oneline // 查看log點線圖
// 符號解釋:
* 表示一個commit， 注意不要管*在哪一條主線上 
| 表示分支前進 
/ 表示分叉 
\ 表示合入

8.3 結論

1、不會因為像使用 merge 時合代碼時遇到沖突產生新的提交記錄

2、用 merge 只需要解決一次沖突即,簡單粗暴,而用 rebase 的時候 ，需要依次解決每次的沖突，才可以提交。

3、使用 rebase 提交記錄不會分叉,一條線干凈整潔

4、沖突解決完之后，使用 git add 來標記沖突已解決，最后執行git rebase --continue繼續。如果中間遇到某個補丁不需要應用，可以用下面命令忽略：git rebase --skip

5、如果想回到 rebase 執行之前的狀態，可以執行：git rebase --abort

8.4 場景三

1. 你開發的一個需求產品反復更改,導致你的commit記錄多次重復功能點
2. 在日常開發中,難免有重復的commit提交記錄.這時候我們想優化一下提交記錄該如何做呢

• 當前分支狀態節點如下圖所示:

使用git rebase 進行commit記錄合并操作

 $ git rebase -i HEAD~x  // i(interactive)交互，HEAD~x 代表要合并到距離HEAD最近的幾個歷史提交,如 HEAD～3就是歷史的前3個提交.$ git log --graph --oneline // 查看log點線圖// 符號解釋:* 表示一個commit， 注意不要管*在哪一條主線上 | 表示分支前進 / 表示分叉 \ 表示合入

• 這里我們使用git rebase -i HEAD~3，此時我們會出現如下界面,我們進行簡單設置

• 

? 此時我們會產生一條新的提交記錄,并選擇填寫提交相關信息,并刪減掉合并掉的提交記錄?

• 到此我們的合并已結束。

8.4.1 結論

1. 合并了冗余的提交記錄,并產生了一條新的提交記錄
2. 使提交記錄看起來更整潔，也方便同事查閱

九、總結

• 我們發現分享 rebase 全文都是圍繞 優化分支提交記錄 來舉例子介紹該命令,我個人覺得這也就是該命令的核心之處。
• 在學習 rebase 之前我日常使用的基本都是 merge 導致 commit 記錄過于混亂

---

參考文獻

• # 從git log 點線圖（graph）看merge和rebase操作

• # 從git rebase的常見沖突及解決辦法