作者回复: 设计这个问题,一来请大家注意“集成分支的回滚”,不能用reset --hard的方式来清除不要的代码,而该使用revert;二来鼓励大家通过实践与思考,真正地掌握revert命令,以便高效解决各类代码回滚的问题。
通过gitlab UI界面,我们只能回滚单个commit,而用git revert命令,可以一次性回滚连续的或间隔的几个commit,其次,如果遇到merge产生的合并commit,必须使用 -m 参数才能回滚,因为要确认正确的父节点
这里还引申出的一个问题是,如果通过UI回滚单个commit不能满足回滚要求的话,建议开发在本地利用revert灵活的方式完成代码回滚,本地测试没问题,再push到远端,然后发回滚的Merge Request。
作者回复: 这些都会在最后的一节中介绍,但是这些其实gitlab的doc都挺清楚的,我还是力求将一些大家不一定了解但却有用的东西
作者回复: 我们说上线后不得已才会回滚集成分支的代码(短时间不能修复A功能代码的问题,而B功能又急着要上线)。
上述操作,我们把集成分支回到正确的地方,并且在集成分支上通过新增一个commit的方式,其意义有4个: 让团队其他成员新拉取的代码都没有问题;让曾经拉取了问题代码的分支merge回集成分支的时候,也不会再次把问题带进来;不会影响其他紧急上线的功能;负责修复问题的开发人员,只需再执行revert就能取到需要修复的代码。
作者回复: 上线前可以通过revert直接处理,纬度是commit;但是上线后,部署包已经存在,你必须考虑与它的对应关系。举个例子,有3个commit,1、2、3上线前你可以回滚1、3,保留2;但上线后,3个commit都要回滚,特别是如果做了自动化代码回滚,这条原则就很重要
作者回复: 没有特别的控制约束,最终是以merge request为单位,多个commit的集合,一个mr基本上就是一个功能
作者回复: 分支策略可以看一下第4讲的内容
作者回复: gitlab高版本对保护分支做了更加精细的权限控制,允许角色或个人(不一定是master)对保护分支做merge和push。这道题主要让大家回顾一下集成分支代码revert的做法,不是删除不要的commit,而是新建一个commit,如果revert的时候不勾选发起merge request,那么这个revert产生的commt就只有一个parent。
发布包本身也是一条路径线,也需要被记录,建议发布包本身带一个比较容易辨识的版本号,commitid作为属性记录在发布包上,这样整个发布包历史也可以很好管理