Git提交信息规范

1. 约定格式

首先,在提交项目代码的时候会进行 git hook 检查,代码提交格式是检查中的其中一项。所以,我们的代码提交需要符合约定的提交格式。

约定的提交格式如下

<提交类型>[(影响范围)]: <本次提交描述> <(禅道号或 bug 号)>

注: []中的内容表示可选,<>中的内容表示必填

2. 格式说明

2.1. 提交类型

提交类型主要包含如下几种:

类别 含义
feat 新功能
fix 修复 bug
merge 合并代码
ui 样式调整
refactor 重构(既不修复错误也不添加功能)
perf 优化相关,比如提升性能、体验

2.2. 影响范围

在提交类型之后,可以选择性地添加本次提交的影响范围(可选的),可以简单的用文字描述范围信息,如下示例:

fix(全局): 修改全局的代码加载方式 (bug#1234)

perf(基金金融大全): 修改大全表格渲染效率 (story#4555)

feat: 添加xxx新功能 (story#2356)
注意事项

当需求处于在开发中,没有发布到 test 时,测试或产品会在禅道上提一些需求相关的 bug,当解决这些 bug 后,提交时不要按照 bug 的方式来提交,需要以需求的方式提交,并在影响范围里填写 bug 号,方便后续升级后的追踪与测试。

例如,在开发#1234 需求时,解决了一个#1234 需求上的 bug#6789,那么,我们的提交方式应该为如下所示:

fix(#6789): 修复xxxx bug (story#1234)

扫描二维码关注公众号,回复: 15629607 查看本文章

2.3. 提交描述

在提交描述部分请填写具体的改动描述,类似于如下的这些描述,不要出现在代码提交中。

fix bug
修复一些问题
添加一些功能

这些描述中无法看到本次提交具体解决了什么问题,所以要避免。

2.4. 禅道号或 bug 号

每一个提交都应该有禅道号,可以为 bug 号,也可以为需求号,但是不要写任务号。

一个任务如何去看需求号?

打开任务详情,在基本信息卡片中有一个相关需求的链接,点击打开。

image

在打开后的弹窗中,如下图左上角即为需求号。

image

注意事项

有时候,有些代码修改确实没有需求号,当然也没有 bug 号,这种改动如何提交代码?

针对于这种现象,在禅道上开了一个2104 需求,这个需求为页面长期优化需求(此需求伴随整个开发周期,所以不会关闭),页面相关的优化提交(无关任何业务需求)或没有禅道号的时候可以使用此禅道号。

由于该需求比较特殊,所以在提交时需要添加影响范围,如下提交格式:

perf(全局): 优化全局的渲染性能 (story#2104)

perf(信用大数据): 优化表格的xxx性能 (story#2104)
该需求号下代码的升级策略:

升级时,会比对 test 与该需求分支,如果存在优化改动,会发布到 test

每次版本迭代周期结束,会汇总整体的性能优化改动,将汇总结果备注到禅道,以供后续追踪与统计。

猜你喜欢

转载自blog.csdn.net/weixin_53334387/article/details/126639701