解决Git Revert 再次合代码无效问题

2022-11-13 15:11:04 代码 无效 再次

背景

开发分支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 合代码无效的资料请关注其它相关文章!

相关文章