相信很多人使用Git等版本控制工具时候都会觉得每次提交都要写一个注释有什么用啊？好麻烦，所以我每次都是随便写个数字就提交了，但是慢慢的我就发现了，如果项目长期维护或者修改很久之前的项目，没有一个清晰明了的注释是多么的DT，我就经历过找回自己之前被修改的代码，然后看到自己写的git commit 瞬间崩溃了，真是自己选的路跪着也要走完呀！于是我就想规范一下自己，所以在网上搜罗了一些相关文章，总结了一下。
Commit Message 格式
每次提交，Commit message 都包括三个部分：Header，Body 和 Footer。
其中，Header 是必需的，Body 和 Footer 可以省略。
不管是哪一个部分，任何一行都不得超过100个字符。这是为了避免自动换行影响美观。
- 标题行(第一行/header): 必填, 描述主要修改类型和内容
- 主题内容(body): 描述为什么修改, 做了什么样的修改, 以及开发的思路等等
- 页脚注释(footer): 放 Breaking Changes 或 Closed Issues
- scope: commit 影响的范围, 比如: route, component, utils, build...
- subject: commit 的概述, 建议符合 50/72 formatting
- body: commit 具体修改内容, 可以分为多行, 建议符合 50/72 formatting
- footer: 一些备注, 通常是 BREAKING CHANGE 或修复的 bug 的链接.
注：该工具要输入时都可以用\n 来换行操作， 回车直接结束描述！！如果想结束重来可以使用ctrl + c
Header
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
type：
type用于说明 commit 的类别。
- feat：新增功能
- fix：bug 修复
- docs：文档更新
- style：不影响程序逻辑的代码修改(修改空白字符，格式缩进，补全缺失的分号等，没有改变代码逻辑)
- refactor：重构代码(既没有新增功能，也没有修复 bug)
- perf：性能, 体验优化
- test：新增测试用例或是更新现有测试
- build：主要目的是修改项目构建系统(例如 glup，webpack，rollup 的配置等)的提交
- ci：主要目的是修改项目继续集成流程(例如 Travis，Jenkins，GitLab CI，Circle等)的提交
- chore：不属于以上类型的其他类，比如构建流程, 依赖管理
- revert：回滚某个更早之前的提交
如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。
scope：
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
subject:
subject是 commit 目的的简短描述，
- 以动词开头，使用第一人称现在时，比如
change，而不是changed或changes - 第一个字母小写
- 结尾不加句号（
.）
