gitlab版本保护及协同开发版本保障规范策略

目录

问题/场景描述

思考过程

第一个问题

第二个问题

解决策略

源头协同开发策略

git 兜底策略

---

问题/场景描述

两个月前碰到一个问题，我负责的一个大业务线，因为比较忙，经常有好几个人同时编辑同一个工程，我属实被坑了一把，有两个人他们在进行开发的时候没有在 gitlab 打新分支出来，直接在测试分支进行了代码更改（这点也怪我，我带他们的时候没有强调一些规范，事后我也做了反思，带新人的时候应该考虑全面点，不能光教技术和经验，规范这块也非常重要）

到这儿你是不是觉得还好，不就是不规范么，下次注意就好，那您继续往下看

因为我们每次进行线上变更是需要好些领导审批的，也需要别得部门协同，定的是下月初上线更新，结果，有一个产品突然发邮件给他们，也抄送给我了，说是考虑到目前的情况，功能延期上线，这就坑了.....

看到这儿你明白哪儿坑了吗？没有？那我给你解释清楚

首先，有好几个不用的产品功能，不同的人开发，其次，这些新的功能都在同一个分支，这个时候，告诉你，有一个需要延期，那就意味着，需要手动拆除代码，不能把该功能放到线上环境商用，最坑的是，需要延期的功能刚好是旧功能迭代，对原代码进行了更改，就算顺利拆除了，也需要相关的所有功能做回归测试..... 并且，产品没有提前沟通，直接邮件通知说要延期，也不做评估能不能随便延期

这是多么大的任务量，测试组的负责人和我都疯了，临时加工作，还是那种不一定能完成的

但是大家还是紧赶慢赶，把代码手动拆出来，测试同事挨个进行回归测试，还是保证了正常的线上程序变更，但，从这次的这个问题，我思考了一下该如何规避掉这一系列的问题，到目前为止，我制定的规范已经实行了两个月，没有出现问题，也已经推广到公司内部其他team使用，分享给大家，仅供参考交流，不足之处请多指教

思考过程

首先，在这次的过程里，明显出现了两个问题

1、多人开发时，代码版本分支上的混乱

2、多个功能绑定，但其中某个功能不能正常发布，影响了其他功能

对应这两个问题，需要挨个解决

第一个问题

多人开发时，代码版本混乱，既然如此，那就从两方面入手

1、要求相关研发人员，按照规范提交编辑代码

2、设置Git保护，收缩管理权限，防止误操作，误提交

第二个问题

第二个问题也有两个办法可以解决

1、规范相关产品、业务侧，要求其不得随意变更已经确定的发布更新时间

2、功能点之间进行拆分，最小粒度进行各自功能的研发

对于第一点，其实很多时候我们是无法控制的，毕竟受影响的因素有很多，但，我还是给相关的leader发了邮件，要求不得随意变更既定时间，如有问题，需及时沟通解决，不得自行决定延期或功能取消，且仅用一封邮件通知变更，否则，研发无法保证能否满足其要求

解决策略

上面说了两个问题的思考过程，那就是怎么落地实施了

源头协同开发策略

这点是要求相关的研发同事遵照规范进行开发、提交

具体措施如下：

1、每次线上进行变更完成后，遵照以往，将代码合并至线上代码备份分支，保证线上如果出问题的话可以进行紧急修复

2、每次新的功能，都基于线上代码备份分支打出新的分支进行

3、 创建单独的测试分支，测试分支从线上代码备份分支打出，对应功能开发完成后，合并到测试分支

4、不同的线上服务变更日期创建自己单独的备发布分支，如wait_2022_04_15，wait_2022_04_22，从每次最新的线上代码备份分支打出，测试完成等待线上发布的功能合并到备发布分支

5、进行线上发布时，采用备发布分支进行对应的构建、发布

6、线上发布完成后，将备发布分支合并至线上代码备份分支，删除备更新分支

7、线上发布完成后，从线上代码备份分支标记对应的tag，命名为变更日期命名，如2022_04_14

8、线上代码备份分支、备发布分支都启用分支保护，调整权限，只有管理者有完整操作权限，其他开发者只可以申请发起合并，不可以直接操作，由管理者进行审批

9、所有的线上变更，由管理者管控，进行备份、保护、撤销、删除

当然，具体措施不止这点，在我给相关研发人员的邮件里，我一共写了二十多点，出于保密及业务架构的特色化，我就省去了没写，只写出了关键部分，各位大佬可以作参考，如果有觉得不好的可以改进的部分，可以私信或者评论小的，都可以~

git 兜底策略

Git主要是为了兜底，防止相关人员不遵守规范进行误操作，所以依赖于Git的分支保护

设置→版本库  就可以看到分支保护

看这个英文，就可以看到知道，这是保护分支

选择对应的分支，选择可以操作的角色是什么--记得更改对应人员的角色权限

更改完成后，就可以看到已经受保护，没有权限的人员是不能提交、合并、删除受保护分支的

这样，就解决了问题

好了，今天的分享就到这里，都早点休息吧