背景
将开发分支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上的所有功能代码变更
以上就是解决Git Revert 再次合代码无效问题的详细内容，更多关于Git Revert 合代码无效的资料请关注阿兔在线工具其它相关文章！
