​说明

我们要求每一行代码都以Gitlab Merge Request的形式合并提交，通过Merge Request的形式合并的代码不会直接提交到开发分支，需要由该工程的Maintainer或Owner在线检查代码后确认合并才算完成，这种方式就是一套标准的代码Review。

根据过去数年的经验，代码Review的价值是非常高的，一个开发不可能掌握所有技能，也不可能所有更改都考虑全面，通过同行评审能从另一个角度发现代码中潜在的问题。

Gitlab是一个独立系统，代码合并人不可能随时在线关注合并请求，为了让合并人及时处理，我们在Gitlab上挂载了一个监控微服务，将每一例合并请求都发送到协同系统中，让Maintainer能及时收到合并消息并立即处理。

同时V5基于Flink自研了一套灵活的CICD编译构建流程：在接收到Git合并请求后会进行代码编译、Sonar静态代码检查、启动有效性测试，任何一个环节异常都不会将编译结果同步到构建包，保障我们的代码稳定有效。

本章介绍整个合并流程规范，请开发按照规范执行。

======================================================================

提交规范

提交人要求设置为姓名，不使用git账号，方便排查日志能快速定位到修改人员。

设置方式：

​

需要多个的，可以这样配置：

​

代码合并流程图

如下是完整的代码合并流程图，供大家总体查阅整个体系结构：

​

======================================================================

代码修改人操作规范

代码修改人需要通过[创建私人分支->私人分支修改代码->push代码到私人分支->合并请求到开发分支]这几个步骤完成代码的修改和合并请求，详细操作如下。

1）首先要确认自己本次代码合并的目标分支是哪一条，以V8.1为例，V8.1的开发分支为：standard-V8.1-develop

如果自己不清楚代码合并到什么分支，一定要找指导人确认

2）选择新建分支：通过Gitlab在线新建分支，如下图所示（开发也可以通过自己的IDE开发工具新建分支）

注：只有Developer及更高级别角色才能新建分支，如果你无法操作则可能是Reporter（考虑申请更高权限或将代码传送给指导人提交）

​

3）基于源开发分支Create私人分支：Branch name对应私人分支名，Create from表示复制自哪个源分支。

我们要求Branch name私人分支名格式为：BUG号_个人姓名。

• 如修改JIRA BUG则命名为：V5-9724_zhangsan（V5-9724是JIRA BUG编号）；

• 如修改客户BUG则命名为：BUG2021081055809_zhangsan（BUG2021081055809是客户BUG流水号）；

• 如两者都不是，单纯发现不规范代码，需要修改，则可以命名为：fixbug20210810_zhangsan，这种有一定日期+身份信息的分支。

​

请不要以源分支名做前缀（如standard-V8.1-develop_zhangsan，这是不允许的！），如果后续不及时清理会导致非常多的干扰分支，影响开发使用。

​

4）创建出私人分支之后，通过开发工具拉取自己创建的私人分支到本地。

• 如果你本地没有这个project，则通过开发工具将此工程import from git到本地，选择orgin/V5-9724_zhangsan（自己的私人分支名）完成私人分支的拉取

• 如果你本地已经有这个project，则通过先pull一次，再Switch to切换到Remote Tracking远程分支orgin/V5-9724_zhangsan（自己的私人分支名），通过checkout to local完成私人分支的拉取

​

5）修改+提交代码：随后修改私人分支代码，再将修改的代码通过commit->pull->push三步标准操作提交到Gitlab远程分支上。此时就完成了私人分支的代码提交操作。

【无图】

6）检查提交记录+创建合并请求：

回到云端Gitlab服务器，切换到自己的私人分支能够看到刚才自己提交的代码记录。

检查修改无误后，通过“创建合并请求”按钮进行代码合并申请。

​

7）（非常重要）填写合并信息：

①首先确认“从[私人分支]到[目标开发分支]”信息是否准确

②标题输入完整的BUG信息：JIRA BUG填写“BUG编号+BUG标题描述”；客户BUG填写“BUG流程的标题+BUG流水号”

③描述框内增加必要的描述，以方便代码Reviewer能很快理解你的修改思路。如果是临近发版，代码冻结期，还需要填写测试范围，以方便后续测试验证参考

④指派人：就是代码检查人，我们已经将合并请求与公司系统打通（后面内容介绍）。不选择指派人则默认流转到project工程负责人，如果自己选择了指派人，则会将合并请求流转给自己指定的指派人手里。

⑤合并选项（全部推荐勾选）：“Delete source branch...”意思是合并完之后，此分支作废（自动删除），防止私人分支泛滥。“Squash commits ...”意思是当你私人分支提交了多条commit记录，通过此操作能将多条记录合并成仅一条记录，以保障提交记录的整洁。

⑥最后Submit合并请求就不赘述

​

自此，开发人员的代码合并操作全部完成。再次总结，整个合并过程包含[创建私人分支->私人分支修改代码->push代码到私人分支->合并请求到开发分支]这几个步骤。

======================================================================

代码合并消息分发微服务

当开发人员Submit合并请求之后，需要等待Maintainer进行代码检查和正式合并操作，而如果Maintainer没有登录Gitlab则无法知晓合并信息。

我们开发了一套Gitlab合并请求的监听和消息分发微服务，在监听到开发人员合并申请时，我们根据合并请求上面的信息找到对应工程代码合并人（Maintainer），自动触发一条表单合并流程，同时通过致信发送一条消息。

代码合并表单流程：

​

致信消息：

​

======================================================================

代码合并人Maintainer操作

1）代码合并人在协同中能收到合并请求的表单流程，“检查结果”和“协助检查人”二选一必填：你可以选择自己检查并合并代码；如果你觉得这个代码并不熟悉，需要更熟悉的开发经理检查，则可以选择协助检查人。

​

2）如果你需要别的检查人协助代码Review，直接指定检查人，提交流程即可，当前合并流程会流转到协助检查人。

​

3）如果你要自己检查代码，代码检查人通过表单上面的Merge URL直接打开Gitlab

​

4）在Gitlab合并代码页面，Maintainer会显示如下界面，主要关注如下1、2、3三个位置的操作按钮：

• ①点击“变更”按钮能看到修改的源代码

• ②如果代码无误，点击“合并”即可

• ③如果代码有误，点击底部的“Close”操作关闭请求（你也可以点击右上角“标记为草稿”旁边的箭头关闭本次提交请求）

​

注意，大文件默认是不会加载对比，Maintainer需要点击旁边的操作按钮，大文件通过“在Web IDE中编辑”操作进行源代码的检查。

​

5）以上Gitlab操作完成之后，回到协同表单页面填写检查结果，检查结果包含：通过、不通过、链接无效几个选项，如果代码有问题并且被Close就选择不通过，并且备注不通过原因。

​

6）关于测试审核：如果当前版本处于最后即将发版阶段，我们将进入限制性提交时期，要求每一行代码提交都需要经过测试检查。Maintainer需要协助填写本次代码的测试人，选择之后会自动流转给测试人验证。

​

异常处理情况

如果存在合并冲突，选择Close Merge，同时表单中选择“不通过”。

​

======================================================================

同行评审规范

代码进入冻结期，意味着项目趋向发版，此时每一行代码的提交都要经过严格审查。如果代码审查人不熟悉业务，漏掉了关键信息，就容易出现“改一送三BUG”的情况。

故代码冻结期将进行代码加强审查的机制：除了代码合并人审查外，再加上额外的同行评审。具体执行策略如下：

​

在Maintainer合并代码之后，如果当前工程有同行代码评审人员，则会再流转到同行代码评审人员侧，由这些同事做代码的二次检查。

同行评审职责：同行评审人员可以点开merge request，检查代码变更记录，利用自己的经验再判定一下开发提交的代码是否正确，填写问题明细表。

如果不正确，则在表单重复表上增加一行问题记录，随后直接处理协同即可，问题会流转给发起人↓↓↓

如果代码逻辑有严重问题，同行评审人员可以记录问题，并回退给代码合并人员，让合并人revert（还原）代码。

​

同行评审人员来源

那么我们工程很多，每个工程的同行评审人员都不同，这个数据来源哪里？

我们维护了一张“代码工程信息查询”的底表，可以在上面设置每个工程的负责人和同行代码评审人员，如果Master需要更新同行代码评审人员，可以联系QA更新底表数据。

​

======================================================================

CICD编译构建规范

代码提交之后，会进行代码编译构建，构建地址位于：https://build.seeyoncloud.com/#/task/sub

​

CICD构建队列可视化平台提供了：构建进度、分支查询、重新构建、查看失败原因、查看合并详情的能力，所有开发都要掌握其基本能力！

构建进度和状态

代码合并提交之后，CICD平台会每隔5分钟扫描一次提交记录，如果指定工程有提交记录，则自动将工程放入构建队列。

​

编译构建中：表示代码正在编译构建，编译构建将会执行编译->静态代码扫描->模拟启动等多步操作，任何操作失败都会通知

合并中：表示代码检查无误，即将合并到最终包

合并成功：表示构建包生存完成，可以从v5-resource拉取编译后的代码

失败：有多种情况，可能是代码编译失败、可能是静态代码扫描不通过、可能是启动不成功、可能是CICD自身问题，开发需要将数据移动到“失败”上面去看具体问题！

如果是后端代码有依赖（存在两个工程先后执行问题），需要等待前置工程“合并成功”之后，再手动点击“重新构建”来完成编译↓↓↓

​

如果确认自己代码没问题，可能是CICD自身问题，请直接联系CICD如下构建负责人跟进：周龙波、吴春林、田若岑。

Sonar静态代码修改

如果代码编写不规范，sonar静态代码扫描会提示不通过，此时开发需要连接到sonar查看具体问题，并修复问题代码，修复后重新合并代码、重新构建：

​

​

如果你的代码没有问题，被sonar检测错了，可以告知自己的Master，通过Master帐号登录，标记为“误判”↓↓↓

​

其它

删除分支，如果合并过程没有删除私人分支，你还可以通过如下操作进行删除：

​​