Git系列篇二：新參數 --rebase-merges 讓 git rebase 完美變基更強大

前言

以前曾經分享過靈活運用 git rebase，讓團隊協做下的提交記錄整潔些，使用 --preserve-merges 參數（簡寫-p)，能夠像剪刀同樣咔嚓一下將整段分支歷史基於最新 master 分支進行變基遷移，效果很是的贊。

然而，這是理想狀況下的操做，好比你的分支是基於 master 的上一個節點進行開發且期間並無和 master 進行互動，那麼，就可使用git rebase master -p這個命令進行完美變基。

問題來了

可是！咱們經常碰到這樣一個狀況：有不少個特性分支基於同一個master節點同時開發，而後你們合併進test分支一塊兒開始測試，這時候，其中一個特性分支須要先上線它先合進了master分支。

因而仍在測試中的其餘分支表示這個場景很是尷尬，說好的好兄弟共同進退呢。。。

)

改族譜清理門戶

事情已經發生了，test 分支表示再也不認這個兄弟了，更不能忍受本身的提交歷史裏出現這段黑歷史，因而祭出大招git rebase -i，要清理本身的提交歷史。

歷史是任人打扮的小姑娘

git rebase --interactive

簡單的說，--interactive參數（簡寫-i)能夠用來編輯提交歷史，然而在2.17.0版本以前，這個命令配合--preserve-merges並不能作到完美的歷史編輯，甚至在 git --help的文檔裏都直接的指出這個 bug 一直存在，並且存在了不少年-。-

新參數 --rebase-merges

就如PHP跳過了6直接來個7同樣，-i -p的 bug 困擾了你們不少年，忍無可忍一忍再忍，總算一個新的參數--rebase-merges（簡寫-r）從2.18.0版本出現了，這個參數能夠實現若干強大功能暫且不說我也不熟，總之，咱們想要重改歷史這件事如今能夠作到了。

注意：此特性須要git版本2.18.0以上，最好是最新版本。

第一步：清理門戶

在前文裏，咱們說過，要想完美的使用git rebase master -p來基於最新 master 分支進行變基，前提是二者之間不要出現互動交集。

若是出現了交集，好比提交歷史裏的某個特性分支先合併進 master上線了，那麼，就要清理門戶，移除當前測試分支裏的黑歷史。

使用命令：git rebase -i -r c82269475b9....1addb9f3f6fd進行歷史編輯。

此處的 c82269475b9....1addb9f3f6fd 爲當前測試分支的根節點（一般是 master 分支的上一個節點）

還記得上文裏，先跑的分支曾經三次合併進 test 分支麼？在此處，註釋掉這三次合併動做。

清理門戶以後，test 分支的歷史裏就和最新 master 沒有交集了，能夠進行下一步完美變基。

第二步：完美變基

這步簡單，能夠參考前文，使用git rebase master -p來基於最新 master 分支進行變基便可。

後語

變基這件事吧，其實挺違背版本控制的理念的，然而對有潔癖的開發者來講，頭可斷血可流髮型不能亂，因此在溝通良好的團隊或我的開發過程當中，變基用的好，也何嘗不是一件妙事兒。

原文來自阿星的博客： wanyaxing.com/blog/201901…