commitizen规范代码提交

转载连接：https://www.jianshu.com/p/bd712e42f2e9

参考连接：http://www.javashuo.com/article/p-uwfwuejx-ck.html

平时提交的变更信息是应该遵循 Angular 规范 的，标准格式为：

<类型>[可选的做用域]: <描述>

[可选的正文]

[可选的脚注]

提交说明包含了下面的结构化元素，以向类库使用者代表其意图：

1. fix: 类型 为 fix 的提交表示在代码库中修复了一个 bug（这和语义化版本中的 PATCH 相对应）。
2. feat: 类型 为 feat 的提交表示在代码库中新增了一个功能（这和语义化版本中的 MINOR 相对应）。
3. BREAKING CHANGE: 在可选的正文或脚注的起始位置带有 BREAKING CHANGE: 的提交，表示引入了破坏性变动（这和语义化版本中的 MAJOR 相对应）。破坏性变动能够是任意 类型 提交的一部分。对于 fix:、feat: 和 chore:，乃至更多其它的 类型 而言，它都是有效的。
4. 其它在 fix: 和 feat: 以外的提交 类型 也都是支持的，例如 Angular 约定 中推荐使用 docs:、style:、refactor:、perf:、test:、chore:，但这些标签在约定式提交规范中并非强制性的。

其余标签含义：

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

约定式提交规范

本文档中的关键词 “必须”、“禁止”、“须要”、“应当”、“不该当”、“应该”、“不该该”、“推荐”、“能够” 和 “可选” 应按照 RFC 2119 的描述解释。

1. 每一个提交都必须使用类型字段前缀，这由一个形如 feat 或 fix 的名词组成，其后接冒号和空格。
2. 当一个提交为应用或类库实现了新特性时，必须使用 feat 类型。
3. 当一个提交为应用修复了 bug 时，必须使用 fix 类型。
4. 可选的做用域字段能够在类型后提供。做用域是描述代码库中某个部分的词组，封装在括号中，形如 fix(parser): 等。
5. 描述字段必须紧接在类型或做用域前缀以后。描述指的是对代码变动的简短描述，形如 fix: array parsing issue when multiple spaces were contained in string.
6. 在简短描述以后，能够编写更长的提交正文，为代码变动提供额外的上下文信息。正文必须起始于描述字段结束的一个空行后。
7. 在正文结束的一个空行后，能够编写脚注（若是正文缺失，能够编写在描述以后）。脚注应当为代码变动包含额外的 issue 引用信息（例如它所修复的 issue，相似 Fixes #13 等）。
8. 破坏性变动必须在提交的正文或脚注加以展现。一个破坏性变动必须包含大写的文本 BREAKING CHANGE，紧跟冒号和空格。
9. 在 BREAKING CHANGE: 以后必须提供描述，以描述对 API 的变动。例如 BREAKING CHANGE: environment variables now take precedence over config files.
10. 脚注必须只包含 BREAKING CHANGE、外部连接、issue 引用和其它元数据信息。
11. 在提交说明中，能够使用 feat 和 fix 以外的类型。

为何使用约定式提交

• 自动化生成 CHANGELOG。
• 基于提交的类型，自动决定语义化的版本变动。
• 向同事、公众与其余利益关系人传达变化的性质。
• 触发构建和部署流程。
• 让人们更容易地探索结构化的提交历史，下降贡献项目的难度。

如今终于轮到 commitizen 出场了，下载地址：https://github.com/commitizen/cz-cli

安装

npm install -g commitizen

在项目目录里，运行下面的命令

commitizen init cz-conventional-changelog --save --save-exact

这样以后，凡是用到git commit命令，一概改成使用git cz。会出现选项，用来生成符合格式的 Commit message。

注意：若是项目中存在多个modules，那么只需在根目录安装便可。

validate-commit-msg

那么，有了规范，对于懒人来讲依然可能不去遵照，这时就须要这个插件来进行提交检查

将 validate-commit-msg.js 放到项目根目录下，并加入 Git 的 hook。

"config": {
    "ghooks": {
      "commit-msg": "./validate-commit-msg.js"
    }
  }

每次git commit 的时候，这个脚本就会自动检查 Commit message 是否合格。若是不合格，就会报错。

$ git add -A 
$ git commit -m "edit markdown" 
INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" ! was: edit markdown

conventional-changelog

最后，当咱们能够经过 conventional-changelog 来自动生成 change log 了。

npm install -g conventional-changelog
$ cd my-project
$ conventional-changelog -p angular -i CHANGELOG.md -w

上面命令不会覆盖之前的 Change log，只会在CHANGELOG.md的头部加上自从上次发布以来的变更。
若是你想生成全部发布的 Change log，运行下面的命令：

$ conventional-changelog -p angular -i CHANGELOG.md -w -r 0

为了方便，将其写入 package.json 的scripts字段：

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

直接运行：

$ npm run changelog