规范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相关，附带就可以。
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上可以看到提交内容
