Git commit规范
作用：
- 能加快
Code Review的流程 - 根据
Git Commit的元数据生成Changelog - 后续维护者可以知道
Feature被修改的原因
技术方案
提交的格式要求
一般来说
type
type 代表了某次提交的类型，比如是修复一个 bug 还是增加了一个新的 feature。所有的type 类型如下：
feat：新增featurefix：修复bugdocs：仅仅修改了文档，比如README、CHANGLELOG等等style：仅仅修改了空格、格式缩进、多行等等，不改变逻辑refactor：代码重构，没有加新的功能或者修复bugperf：优化相关，比如提升性能、体验等test：测试用例，包括单元测试、集成测试等chore：改变构建流程，或者增加依赖库、工具等revert：回滚到上一个版本
Scope
scope 字段用于说明本次 commit 所影响的范围，比如视图层、数据模型或者路由模块等，是一个可选参数。
subject
subject 字段是本次 commit 的一个概要，需要用最简洁的语言来说明本次修改的内容。
Body
可以使用多行文本详细地说明本次提交所改动的一些细节，从而帮助后续的使用者们更好地了解代码的内容。
Footer
Footer 部分只用于两种情况。
- 不兼容变动
如果本次的 commit 与前一个版本的代码无法兼容，那么 Footer 部分需要以 BREAKING CHANGE 开头，后面描述本次变动的详细情况以及迁移到新版本代码的方法。
- 关闭
Issue
如果当前 commit 针对某个 issue，那么可以在 Footer 部分关闭这个 issue 。以 Close 开头，后面用 # 号标识对应的 Issue 号码。
其次还可以用 validate-commit-msg
使用 validate-commit-msg 在提交之前验证 commit 信息是否符合要求。同时使用 husky 来为本地开发阶段增加 precommit 钩子
Commitizen
如果你觉得自己写规范的 comment 信息太麻烦，那么你可以使用Commitizen ，这是一个是一个撰写合格 Commit message 的工具。