规范Commit格式

规范Commit格式

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

Conventional Commits

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

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

格式

原文

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

译文

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

格式说明

示例如下:

type

1. fix: 类型 为 fix 的提交表示在代码库中修复了一个bug。
2. feat: 类型 为 feat 的提交表示在代码库中新增了一个功能。
3. perf：类型 为 perf 的提交表示在代码库中做了性能优化。
4. style：类型 为 style 的提交表示在不影响代码含义的变化(空白，格式化，缺少分号等)。
5. docs：类型 为 docs 的提交表示仅更新文档。
6. refactor：类型 为 refactor 的提交表示重构，不修复 bug 且不添加功能。

示例属于新增功能，所以使用了feat。

optional scope

范围必须是一个描述某部分代码的名词，并用圆括号包围。
示例只影响到BlankSystem，所以scope写的是这次只针对BlankSystem。

description

描述字段必须直接跟在<类型>(范围) 前缀的冒号和空格之后。 描述指的是对代码变更的简短总结。
示例总结主要是为了能让非开发(PM)看懂，方便写release note，所以尽量用大家都知道的描述。

optional body

在简短描述之后，可以编写较长的提交正文，为代码变更提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
示例简短描述是为了给非开发(PM)查看，正文是尽量让研发内部直接看懂，这里建议大家尽量写的清楚详细。

optional footer(s)

如果和每个jira相关，附带就可以。

CLion示例

1. 下载插件Conventional Commit

2. Commit窗口打钩需要push的文件，然后邮件选择Commit Files...

3. Commit窗口左下角Amend左键红圈

4. Build Commit Message填好更新内容，然后会自动更新到Amend

5. Amend窗口点击Commit and Push...，然后在Push Commits to xxxx的窗口push

6. 最后在Bitbucket上可以看到提交内容