背景

將開發分支dev合并進主分支main以后，如果發現bug需要回滾代碼時，我們常使用git revert完成操作，但是當我們將dev上的bug修復之后想再把它合進main卻會發現，dev上的功能代碼合不進去了，原因是這些功能代碼的commit已經在main分支上了（雖然被revert了，但仍在），所以git會拒絕合進重復的commit。

本人最近就遇到了這種問題場景，查閱網上資料推薦的做法一般是把main之前的revert再revert掉然后合dev，但是實際操作過程中卻發生了如下錯誤：

不明就里，估計是因為多人協作導致main分支日新月異，revert操作產生了不可描述的沖突，翻看長串的git log已難以厘清... ...但我決定不去深究這些細節，因為已想到更完美的解決方案??！

那就是利用git rebase -i將dev的commit們 squash（壓縮）為一個commit（主要目的是生成一個新的commit哈希），然后再去rebase main分支即可，實測效果拔群??再也不用擔心類似的問題了！

Demo復現該問題

• 初始狀態：基于main分支切了dev分支并開發

• dev合并到main后

• 發現bug，在main上進行回滾

• 在dev上做bugfix并測試OK

• dev重新合并到main

到這里問題來了，我們希望得到的main分支效果應該相當于以下分支：

c0 <- c1 <- c2 <- c3 <- c4

但由于c2 c3被revert掉（改動內容消失了），卻已經存在于main上（重新合并時main分支認為已經合過它倆，于是拒絕重復引入c2 c3），所以到第5步得到的效果實際相當于：

c0 <- c1 <- c4

這就是標題所說「Git Revert之后再次合代碼無效」的問題

用Squash方式解決該問題

在上述Demo的步驟4基礎上改

1、切到dev執行git rebase -i，讓它自己rebase自己，目的是把dev上多個commit squash（壓縮合并）為一個commit，這個新commit將具有新的哈希值（這樣main分支就不會拒絕它了）

我們希望將c2 c3 c4合并（即dev分支上完整的變更內容），假設c2的哈希值為c2_hash，需要執行以下shell命令

$ git checkout dev
$ git rebase -i c2_hash

2、彈出的vi編輯界面如下，根據提示squash掉dev上的commit

3、填寫commit信息，dev squash完成，效果如下

4、再用dev去rebase main分支，此時我們可以徹底忘掉git revert的黑歷史，就像將一個新鮮出爐的功能分支rebase主分支一樣，有沖突解決沖突即可

5. 再次將dev合并到main即可，完美收官！

小結

解決git revert副作用問題，網上主流的方法是：

• 在main分支找到之前revert的commit（可能有多個，如果是多人協作則還可能分散）
• 將之前的revert再次進行revert
• 合dev分支，解決沖突

本文介紹的方法是：

• 在dev分支上找功能代碼涉及的commit（開發分支上一般是連續的幾個commit，容易找）
• 將這些commit壓縮合并為一個
• dev分支rebase到main分支，解決沖突

個人比較傾向于本文這種做法，一則處理起來比較舒服，完全不用去關心之前的revert記錄；

二則看起來舒服，處理完之后dev分支較main分支只會多一個commit，這個commit包含dev上的所有功能代碼變更