规范使用gitlab开发

日常开发中使用gitlab并行开发时，如何使各个开发人员开发完后提交的代码不冲突，发布生产时不漏发代码，对于我们开发人员来说是很重要的，也是必须掌握的，如果分支管理的不好，大家提交上来的代码可能就会很混乱了，下面是我们公司当前对分支使用的规范与分支使用的方法，就目前使用情况来说，效果不错。

一.分支命名&使用

• master：只做为备份分支
  所有新代码在发布完生产环境后，需要测试同学验证无误后，将发布分支合并到master中，下一个开发再基于master切新的开发分支

• feature_功能名： 按功能标识的分支
  该分支主要用于开发某项功能的研发，待研发完毕后，合并到发布分支release_发布日期

• release_发布日期：安发布日期标识的分支
  该分支主要用于发布生产，如release_20220429表示所有需要发布的功能代码都要合并到该分支，该分支一般由发布日当天从master中checkout出来

• hotfix_发布日期：按日期标识的分支
  该分支只要用于紧急修复bug，当日从master中checkout出来的分支，待新代码发布到生产确定修复了，就将该分支合并到master中去

二.图解过程

三.发布校验

当测试人员提交了新分支的版本commit_id申请发布生产时，发布平台需要对此分支的commit_id中代码进行校验，该步骤主要是用来确保不会漏发代码或者删除掉生产环境的代码导致故障。

1. 当前发布分支的commit_id 为该分支的最新hash
2. 当前发布的分支中包含master中的最新hash
3. 上一次发布到生产的commit_id有没有存在与当前master分支中

对应解释：
1.只发发布分支的最新版本，即分支确认需要发布后，研发人员应该对分支进行封版，不允许往发布分支添加新的代码了，以免漏发代码扯皮甩锅
2.确保当前的分支是基于当前最新master中checkout出来的，即代码是基于生产环境中来新增的代码，否则可能会导致丢失已经发布到生产环境的代码
3.主要是校验上一次发布到生产的分支是否合到master，即确保master分支的代码与生产上运行的代码要一致性