规范Commit格式
Jenkins根据对比当次构建和上次构建的Commit信息来生成ChangeLog,但因为我们目前的提交不够规范,经常有类似"#","update"这列的提交,无法提供给PM有效的更新记录,所以建议大家尽量规范Commit格式。
Conventional Commits
目前推荐大家是有这套规范,如果大家有更好的可以推荐使用,官网链接如下:
Conven tional Commits
官网介绍的很详细,要求也比较多,有一些我们可能也用不到,而且也会增加学习难度,所以我这边整理了一下适合我们的规范,比较简单,但应该够用,
格式
原文
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
译文
<类型>[可选 范围]: <描述>
[可选 正文]
[可选 脚注]
格式说明
示例如下:
type
- fix: 类型 为
fix
的提交表示在代码库中修复了一个bug。 - feat: 类型 为
feat
的提交表示在代码库中新增了一个功能。 - perf:类型 为
perf
的提交表示在代码库中做了性能优化。 - style:类型 为
style
的提交表示在不影响代码含义的变化(空白,格式化,缺少分号等)。 - docs:类型 为
docs
的提交表示仅更新文档。 - refactor:类型 为
refactor
的提交表示重构,不修复 bug 且不添加功能。
示例属于新增功能,所以使用了feat
。
optional scope
范围必须是一个描述某部分代码的名词,并用圆括号包围。
示例只影响到BlankSystem,所以scope写的是这次只针对BlankSystem。
description
描述字段必须直接跟在<类型>(范围) 前缀的冒号和空格之后。 描述指的是对代码变更的简短总结。
示例总结主要是为了能让非开发(PM)看懂,方便写release note,所以尽量用大家都知道的描述。
optional body
在简短描述之后,可以编写较长的提交正文,为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
示例简短描述是为了给非开发(PM)查看,正文是尽量让研发内部直接看懂,这里建议大家尽量写的清楚详细。
optional footer(s)
如果和每个jira相关,附带就可以。