一、为什么需要规范？

无规矩不成方圆

如果你有一个项目团队，从始至终都是自己写，那么你想怎么写都可以，没有人可以干预你。可是如果在团队协作中，大家都张扬个性，那么代码将会是一团糟，好好的项目就被槽践，不管开发还是日后维护，都将是灾难。

这时候，有人提出为何不同统一标准，大家都按照这个标准来，于是Eslint,JSHint 等代码工具如雨后春岁般涌现，成为项目构建的必备良品。

Git Commit规范可能并没有那么夸张， 但如果你在版本回退的时候看到一大段糟心的
Commit,空拍会懊恼不已，所以严格遵守规则，利人利己。

具体规则

先看看公式

1 | <type>(<scope>): <subject>

• type

  • 用于说明Commit的类别，只允许使用下面7个标识。

    feat：新功能（feature）
    fix：修补bug
    docs：文档（documentation）
    style： 格式（不影响代码运行的变动）
    refactor：重构（即不是新增功能，也不是修改bug的代码变动）
    test：增加测试
    chore：构建过程或辅助工具的变动
    

• scope

  • 用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。

• subject

  • 是 commit 目的的简短描述，不超过50个字符。

  1.以动词开头，使用第一人称现在时，比如change，而不是changed或changes
  2.第一个字母小写
  3.结尾不加句号（.）
  

Commit 规范的作用

1. 提供更多的信息，方便排查与回退
2. 过滤关键字，迅速定位；
3. 方便生成文档；

生成 Change log

正如上文提到的生成文档，如果我们的提交都按照规范的话，那就很简单了。生成的文档包括以下三个部分：

• New features
• Bug fixes
• Breaking changes.

每个部分都会罗列相关的 commit ，并且有指向这些 commit 的链接。当然，生成的文档允许手动修改，所以发布前，你还可以添加其他内容。

这里需要使用工具 Conventional Changelog 生成 Change log ：

npm install -g conventional-changelog
cd jartto-domo
conventional-changelog -p angular -i CHANGELOG.md -w

为了方便使用，可以将其写入 package.json 的 scripts 字段。

{
  "scripts": {
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0"
  }
}

这样，使用起来就很简单了：

npm run changelog