当前位置:   article > 正文

(附Git的cherry pick神操作)GitLab远程分支多次合并后发现其中一次有问题该如何解决和回滚?_gitlab cherry-pick

gitlab cherry-pick

目录

问题现象:

问题分析:

1、不需回滚

2、需要回滚

解决方法:

步骤1:

步骤2:

步骤3:

步骤4:

步骤5:

拓展:git代码回滚的可视化操作和命令操作

可视化操作步骤:

命令操作:


问题现象:

        最近在项目中遇到一个git分支代码回滚的问题,如下:

        在GitLab上的远程分支已经合并过多次了,但是突然发现之前的某一次合并的代码存在问题此时该如何解决和回滚?


问题分析:

        出现这种现象,很显然是本地分支提交和推送代码(commit&push)后没有检查清楚并确保代码的正确性,就已经合并(merge)远程分支上了。

        有时候难免会有些误操作,这是可以理解的,毕竟大部分时候程序员都是很忙的。

        当然,出现这种问题时,首先我们最好是先定位到有问题的合并记录,并找到对应的操作人,然后再根据实际情况处理。

        基本上就两种方式,根据实际情况大家酌情使用【这里假设操作人就是我自己】:

1、不需回滚

        适用于问题代码量不多问题代码自己很熟悉(问题代码就是自己写的)的情况。

        此时我可以直接在本地分支上对问题代码进行手动修正,然后再重新提交、推送、合并到远程分支去,这样就能覆盖掉原本的问题代码了;

        这也是程序员几乎都知道的方式。

2、需要回滚

        适用于问题代码量很多问题代码涉及到他人的情况。
       因为问题代码太多了,如果一一修改会浪费很多时间,而且不一定能改对,所以建议回滚后重新合并。

        注意,这里提到的“涉及到他人”,是指问题出现的直接原因,是因为我的某些git操作导致我的旧代码覆盖了他人写的新代码(如commit&push了一些很久以前本地缓存的代码,而他人早已对这部分代码的功能做了很多修改了,结果自己没意识到本次git操作中居然参杂了旧代码,结果覆盖了他人的代码导致出现了问题)。

        其实这种误操作的情况极少出现,所以大家也不需要太慌。一般都是因为本地缓存代码过于久远导致的。

        感兴趣的朋友可以查看我的另一篇文章,里面就有一个经典案例(本文其实就是为了那篇文章出现的问题而写的)。

        经典案例-文章链接:

(附Git的cherry pick神操作)如何解决gitlab合并分支请求时的代码改动(commits和changes)与本地分支的(commit&push)不一致的问题-CSDN博客


解决方法:

        不需回滚的方式,其实就和正常的代码改动、提交&推送、合并分支是一样操作步骤,这里就不提了,下面着重提一下需要回滚的方式的可视化操作步骤:

       警告:

        代码回滚是一个非常慎重的操作,切勿轻易执行。

        注意:

        如果是多人开发,那么回滚的时候有可能会有其他人还在提交代码,所以建议在进行以下回滚操作步骤的过程中,先通知其他人不要做代码提交操作。

步骤1:

        先定位到有问题的合并记录(以下简称“问题记录”),找到该记录的操作人。

步骤2:

       回滚代码(建议先对远程分支进行copy备份,防止回滚操作有误)。

        如果问题记录后面(由于倒序原因,从界面上看就是问题记录的上面),已经没有其他的代码提交记录了吗,则可以直接打开该记录,点击界面中的Revert回滚按钮,让代码回滚到该记录之前的状态:

        而如果问题记录后面,还有其他的代码提交记录(如本文开头提到的问题现象),此时也可以尝试点击该记录的Revert回滚按钮,但有可能会出现报错提示(例如unversioned files等,忘记截图了,以后有空再补吧)。

        此时需要根据时间倒序顺序(即从最近的一次提交记录到问题记录)开始,对每个需要回滚的记录,都需要进行回滚。

        依次点击这些记录的Revert回滚按钮,按顺序将代码回滚到问题记录之前的状态。

步骤3:

        创建新的本地分支2

        在IDEA开发工具上,先删除远程分支1对应的本地分支1,这样做是为了清除本地缓存和避免代码污染问题。

        然后重新拉取远程分支1到本地(此时就能保证本地分支1和回滚后的远程分支1的代码完全相同)。

        最后是基于刚拉取的本地分支1,创建新的本地分支2(一般都是不建议直接操作分支1,例如一般都不建议直接在dev分支上进行开发,而是在新的分支上提交&推送代码后,合并到dev分支)。

步骤4:

        在本地分支2重新推送(push)被回滚的代码,让代码维护到最新状态。

        所有被回滚的提交记录涉及代码都需要重新提交(除了被回滚的问题记录设计的代码),才能确保代码维护到最新状态;这里是建议让这些提交记录的操作人,各自去重新提交自己被回滚的代码(当然如果你经验丰富且自信满满,那你也可以自己一个人完成该步骤,不过不太建议)。

        而对于问题记录的代码,首先是要区分出哪些是真正需要提交的、哪些是需要被回滚且不需要再提交的(当然也可以不用手动去区分,因为我们可以使用git的cherry pick神操作快速搞定)。


        关于Git的cherry pick神操作,其实在上面提到的我的另一篇文章中就有提到,所以这里就不再赘述了,感兴趣的小伙伴可以自行前往查看,这里再贴一次文章链接:

(附Git的cherry pick神操作)如何解决gitlab合并分支请求时的代码改动(commits和changes)与本地分支的(commit&push)不一致的问题-CSDN博客文章浏览阅读510次,点赞8次,收藏12次。(附Git的cherry pick神操作)如何解决gitlab合并分支请求时的代码改动(commits和changes)与本地分支的(commit&push)不一致的问题https://blog.csdn.net/weixin_42585386/article/details/138657274


        切换到本地分支2上,在IDEA开发工具的Git-Log窗口找到真正需要提交的代码记录,将它们都cherry pick到当前分支上:

        然后就可以push代码了(需要cherry pick的代码已经被提交过,所以不需要再次commit了)        

步骤5:

        重新发起合并分支请求,将本地分支2代码合并到远程分支1

        记得检查本次合并请求的commit和change记录是否正确,确保不再有问题;合并完后可以对本地分支1进行update操作(即拉取远程分支1的代码),保持远程分支1本地分支1代码是最新且相同的。

        步骤不多,但需要步步为营,谨慎操作,尤其是步骤2和步骤3,。


拓展:git代码回滚的可视化操作和命令操作

可视化操作步骤:

        通过gitlab和IDEA的git按钮来进行操作,不需要书写git命令;适用于需要回滚的代码提交记录不多的情况。

命令操作:

        主要通过git命令来实现,git命令功能更强大有效,但依赖于一定的记忆或笔记能力(要记git命令或搜一下git命令的笔记了)。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/酷酷是懒虫/article/detail/738545
推荐阅读
相关标签
  

闽ICP备14008679号