背景

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

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

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

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

Demo復(fù)現(xiàn)該問題

• 初始狀態(tài)：基于main分支切了dev分支并開發(fā)

• dev合并到main后

• 發(fā)現(xiàn)bug，在main上進行回滾

• 在dev上做bugfix并測試OK

• dev重新合并到main

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

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

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

c0 <- c1 <- c4

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

用Squash方式解決該問題

在上述Demo的步驟4基礎(chǔ)上改

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

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

$ git checkout dev
$ git rebase -i c2_hash

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

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

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

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

小結(jié)

解決git revert副作用問題，網(wǎng)上主流的方法是：

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

本文介紹的方法是：

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

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

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

以上就是解決Git Revert 再次合代碼無效問題的詳細內(nèi)容，更多關(guān)于Git Revert 合代碼無效的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論