假设我们有三个分支,dev1.1是当前代码开发的版本分支,dev是开发环境上部署的版本分支,test是测试环境上部署的版本分支,正常的合并操作应该是dev1.1->dev->test。
某次误操作导致直接从dev1.1合并到了test,此时执行了revert回滚操作,本以为回滚后即撤销了原先的合并,然后继续执行正常的dev1.1->dev->test合并即可。(下图为错误理解示意图)
而实际上revert回滚操作相当于一次commit,即将上一次提交的操作删除后再次提交。此时合并其他BCD没有问题,但当对A修改后再次合并时,dev合并test的时候会有问题。
正确操作应该是在回滚之后,将三个分支反向合并一次,这时候就不会有冲突了
当前补救措施是先将dev(没有A)合并到dev1.1(有A),此时合并会将dev1.1上的A删除,然后手动将本次合并删除的代码加上,提交,接下来按原有流程合并即可dev1.1->dev->test
手动将合并到dev之后删除的A代码加上的时候,可以在gitLog上选择合并前上一次记录的文件,在本地使用Reset Current Branch to Here操作,但是这个只能一个文件一个文件的执行
或者使用git cherry-pick(
可以理解为”挑拣”提交),它会获取某一个分支的单笔提交,并作为一个新的提交引入到你当前分支上。 参考:https://chenchenchen.blog.csdn.net/article/details/112681902
修复前后整个gitLog显示如下(新->旧)
恢复之前版本,reset/revert的回滚操作步骤,参考:https://cloud.tencent.com/developer/article/1873147