提交 Commit 填写规范

  1. 填写描述的格式如下
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<type>:<subject>

空行

<body> 

1.原因分析：无

2.修改方法：无

</body>

空行

【 type说明 】如下：

type 名称 type 说明
新增特性 新的功能点、新的需求
Bug 修复 修复的 Bug：现场的 Bug、测试阶段的 Bug，线上环节的 BUG
文档修改 只是修改了文档：注释，接口、README.md 等
样式修改 不影响代码功能的修改：CSS 样式、代码格式化等
代码重构 代码更改既不修复错误也不添加功能
性能优化 代码更改可以提高性能
测试代码 添加缺失测试或更正现有测试
编译代码 影响构建系统或外部依赖项的更改：pom，dockerfile 等
持续集成 我们的CI配置文件和脚本的更改：Jenkinsfile 等
回退更改 代码回退提交更改
其他提交 除以上所有类型之外的提交更改

【 subject 说明 】如下：

如果提交类型是【Bug 修复】，则简要描述直接填写 Bug 的 JIRA 单或者 DTS 单链接 + 问题描述

如果提交类型是【新增特性】，则简要描述填写对应需求的 JIRA 单 + 需求描述，如需求过于庞大，则应拆分成小的功能点提交代码，便于 Review 人员审核，也有利于 Bug 的回溯

如果提交类型是【代码重构】，则简要描述直接填写对应的 JIRA 单+简要描述

如果提交类型是【性能优化】，则简要描述直接填写对应的 JIRA 单+简要描述

其他不做强制要求，如果有对应的 JIRA 单，则附上 JIRA 单，后面再附上简要描述

**【 body 说明 】如下： **

详细描述，力争语句表达清晰此次提交的代码具体涉及的原因分析和修改方法，如功能点很多则应使用序号列出代码所涉及的功能点。对于 Bug 修复，代码重构，性能优化必须有原因分析，其他可以为空，如下所示

1
2
3
4
1.原因分析：后台代码对于地址进行强 IP 校验
2.修改方法： 
1）取消后台代码对于地址的强 IP 校验
2）支持解析地址从中获取 IP / 域名和端口号

举例说明如下：

1
2
3
4
5
6
新增特性：DCP-175 数据开发-解决方案/业务流程支持操作记录

1.原因分析：无
2.修改方法：
1）增加实时 common 模块 OperateLogHandler 的切入点
2）增加 FlinkSqlTable 控制层的日志收集行为
1
2
3
4
5
Bug 修复：DTS001771957 多次导入实时任务业务流，第一次导入的实时任务业务流的信息未清空

1.原因分析：实时业务流导入时，上传完文件以后点击右上角关闭弹窗，未调用内部清空方法
2.修改方法：
1）关闭窗口时及时调用清空方法
1
2
3
4
5
文档修改：DCP-101 取消离线开发业务流函数

1.原因分析：无
2.修改方法：
1）废弃数据开发业务流函数相关接口
1
2
3
4
5
6
样式修改：统一各模块首页样式，各模块首页展示框部分存在阴影，部分不存在

1.原因分析：无
2.修改方法：
1）样式统一为阴影
2）修改 xxx 模块的展示框
1
2
3
4
5
代码重构：DCP-XXX 数据集成支持不同数据源接口抽象不合理

1.原因分析：通过一个大 json 代表所有参数不利于后续扩展
2.修改方法：
1）剥离出数据源，字段映射，通道控制三大基本信息
1
2
3
4
5
6
性能优化：DCP-XXX 离线开发长时间允许回调速度显著降低

1.原因分析：xxxSQL 查询通过 in 关键字进行匹配，效率低下
2.修改方法：
1）优化 sql 逻辑，通过 join 来规避解决in查询性能低的场景
2）增加部分字段的索引配置
1
2
3
4
5
编译代码：统一 hadoop 版本

1.原因分析：无
2.修改方法：
1）将 xxx 包的版本号修改为 xxx
1
2
3
4
5
回退更改：提交 xxx 代码导致 xxx 模块代码被覆盖

1.原因分析：无
2.修改方法：
1）回退 xxx 模块的代码

提交 Merge 请求规范

  1. 前提：分支可正常构建，特性分支经过验证，其他分支经过充分自验。
  2. 标题（Title）填写说明（必选）：

1）填写本次请求的概述，要求简短且可以看得懂。

举例说明如下：

1
2
下载中心特性合入
数据探索服务启动慢性能优化

对于 Merge 这块的 Title 说明会弱化，不需要强制大家附上相关的 JIRA 或者 WeTrack 单号

  1. Description 填写说明（必选）：

1）填写本次 Merger 的涉及的范围，从大的方面上讲，以 1，2，3 来标识

举例说明如下：

1
2
3
4
5
1.数据接入模块支持下载中心相关代码开发
2.数据标准模块支持下载中心相关代码开发
3.数据组织模块支持下载中心相关代码开发
4.离线开发模块支持下载中心相关代码开发
5.实时开发模块支持下载中心相关代码开发
  1. Assignee 填写说明（必选）：

1）评审人员选择顺序：小组内部成员–模块负责人–系分/开发主管。可以通过 @ 工号或姓名邀请多人评审

2）版本邻近发布阶段（如最后一轮系统测试转测阶段、临时修改内容提供现场时），需要邀请系分、开发主管评审

  1. milestone 填写说明（可选）：

1）里程碑暂时不使用

  1. Labels 填写说明（可选）：

1）保持和 Commit 时候的类型说明一致

  1. 选择是否合入后删除源分支、是否合并提交

1）若 Merge 不需要保留源分支，则勾选：Delete source branch when merge request is accepted

2）若 Merge 时可以合并 commit，则勾选：Squash commits when merge request is accepted

  1. 若主审人没有 Merger 权限，待代码评审完成后，可 @ 如下有权限的人进行 Merge

1）开发主管

2）系分

3）开发部负责人

审批 Merge 请求规范

  1. 同意 Merge 请求时候最后一次填写的评估规范

1）确认合规同意合入备注：必须填写以上 8 个字，防止啥也不看直接点击 Merge ，后续会慢慢放看 Merge 权限，本质上是引导大家需要去做 check

  1. Merge 时需要审核的内容

1）符合 Merge 条件，如已测试通过、已充分自验、可以正常构建

2）请求的填写格式符合规范

3）已经完成代码评审并按规范填写了评审内容

拉分支 / tag 规范

  1. 命名规范：版本号-类别-关键 ID-概述，总计由 4 部分组成，下方会对每部分内容做详细说明

示例：V1.1.6.0-Feature-DCP-198-开源漏洞修复及开源协议合规

  1. 版本号说明 VMP 系统标准版本号：V1.001.0000006.0、V1.001.0000006.1，由项目经理在 VMP 系统建立，走发布流程及公司级流程时必须使用标准写法，其他时间使用缩写

· 缩写版本号：V1.1.6.0、v1.1.6.0，即保留四位，每位去掉所有可以去掉的 0

如：V1.1.10.0，这两个 0 都要保留，前面 10 代表第 10 个版本，后面的 0 代表修订版本

  1. 类别说明

1）新增特性：Feature

2）问题修复：Bug

3）文档修改：Docs

4）样式修改：Style

5）代码重构：Refactor

6）性能优化：Perf

7）测试代码：Test

8）编译代码：Chore

9）持续集成：CI

10）项目定制：Custome

11）发布版本：Gdp

12）其他：Other

  1. 关键 ID 说明

1）针对新增特性类型：必填，关键 ID 为 JIRA 的关键字（单号、特性ID），如 DCP-198

2）针对问题修复类型：必填，关键 ID 为 问题单号。若有多个，仅填写一个重要的即可

3）针对文档修改类型：选填，关键 ID 可以为空，或者是 JIRA 单号

4）针对样式修改类型：选填，关键 ID 可以为空，或者是 JIRA 单号

5）针对代码重构类型：必填，关键 ID 是 JIRA 单号

6）针对性能优化类型：必填，关键 ID 是 JIRA 单号

7）针对测试代码类型：选填，关键 ID 可以为空，或者是 JIRA 单号

8）针对编译代码类型：选填，关键 ID 可以为空，或者是 JIRA 单号

9）针对持续集成类型：选填，关键 ID 可以为空，或者是 JIRA 单号

10）针对项目定制类型：必填，关键 ID 是 JIRA 单号或者 需求单号

11）针对发布版本类型：不需要填写，关键 ID 为空

12）针对其他类型：选填，关键ID可以为空，或者是JIRA单号

  1. 概述说明

1）针对此分支做简洁、清楚的描述，可以是中文也可以是英文

2）对于发布分支，概述填写为：Release

分支保护与清理

  1. 需要保护的分支，提供充分理由后，请有权限的人进行保护
  2. 谁创建谁清理。版本发布后，各小组对不必要保留的分支再次进行审查清理（提交 Merge 时可先做一次筛选）

关于冲突解决

  1. flyway 文件冲突的时候，需要新建一个文件，不允许合并内容。
  2. 特性开发过程中定期执行代码反合的动作，尽量保持和主干代码一致，防止最后一次提交时冲突过于严重。

关于 JIRA 填写规范

  1. JIRA 主要用于流程记录，记录你整个特性开发过程中的主心骨
  2. 每个环节只填写每个环节该输出的东西，养成及时记录的开发习惯
  3. 串讲环节主要填写需求背景，需求的主要实现点，可以附带一些针对 DFX 的考虑
  4. 反串讲环节主要填写串讲环节会后确认的内容和遗漏的内容
  5. 方案设计环节主要填写整个特性实现的关键路径，例如模块图，时序图，流程图等，并且做简要描述，指导整个代码开发
  6. 方案评审环节主要填写对于方案设计环节的补充
  7. 代码开发环节主要填写代码开发过程中遇到的困难（包括联调），这里不需要很细，主要指的那些耗时 0.5 天以上的困难
  8. 代码评审环节主要填写代码评审的相关内容
  9. 转测自验环节主要填写自验的情况，总共多少用例，通过多少用例，需要附上测试用例的清单，防止随意填写