代码提交描述内容随意、质量参差不齐，会降低提交log的可读性和可维护性能。受到Angular提交准则启发，提出了约定式提交规范这种基于提交消息的轻量级约定。
约定提交规范格式
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
规约每一行的含义
为了更好、更规范的提交代码，我们需要了解约定提交规范格式，然后再实战中规范自己的提交。自信满满，哈哈。
type
| type | 描述 |
|---|---|
| feat | 一个新的功能 |
| fix | bug修复 |
| docs | 文档，README.md等 |
| style | 重构在代码,不修改代码含义包括空白行、代码格式化、标注等 |
| perf | 提高代码性能 |
| refactor | 代码修改，既不不是修改bug也不是新增feature |
| test | 新增缺失的单元测试或纠正已经存在的测试 |
| build | 构建修改和额外依赖npm，docker等 |
| ci | 与CI有关的变动(Travis，Circle，BrowserStack)等 |
| revert | 回退一次提交 |
| chore | 不修改test和src的其余变动其他 |
| deps | 升级依赖 |
scope
必填项，格式为项目名/模块名，多个模块拆成多个Commit。例如： spider/xiguadaili
subject
提交的简短说明
body
详细描述，小要求不做修改，重大需求更新需要把添加body说明
footer(affect issues)
指明影响的问题，一般是一个issure或JIRA或需求文档
break changes
指明破坏性修改，比如版本升级，接口参数减少、接口删除、迁移
查看并筛选Commit的目的
查看
git log <last tag> HEAD --pretty=format:%s
筛选
git log <last release> HEAD --grep feature
(Git Commit Template)一款idea插件
点击Ok之后,commit信息结构如下：
fix(project_name/module_name): xxxxxxxxxxxxxx
1.日志链路跟踪traceId
2.xxxxxxxxxxxxxx
Closes www.github.com/wencaixu
提交之后Gitlab格式
欢迎关注我的公众号：看相声也要敲代码
