背景

将开发分支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命令

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上的所有功能代码变更