(资料图片)

规范Commit格式

Jenkins根据对比当次构建和上次构建的Commit信息来生成ChangeLog，但因为我们目前的提交不够规范，经常有类似"#","update"这列的提交，无法提供给PM有效的更新记录，所以建议大家尽量规范Commit格式。

Conventional Commits

目前推荐大家是有这套规范，如果大家有更好的可以推荐使用，官网链接如下：Conventional Commits

官网介绍的很详细，要求也比较多，有一些我们可能也用不到，而且也会增加学习难度，所以我这边整理了一下适合我们的规范，比较简单，但应该够用，

格式原文

[optional scope]:         [optional body]        [optional footer(s)]

译文

<类型>[可选 范围]: <描述>        [可选 正文]        [可选 脚注]

格式说明

示例如下:

typefix:类型为 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相关，附带就可以。

CLion示例1. 下载插件Conventional Commit2. Commit窗口打钩需要push的文件，然后邮件选择Commit Files...3. Commit窗口左下角Amend左键红圈4. Build Commit Message填好更新内容，然后会自动更新到Amend5. Amend窗口点击Commit and Push...，然后在Push Commits to xxxx的窗口push6. 最后在Bitbucket上可以看到提交内容