轉載鏈接：https://www.jianshu.com/p/bd712e42f2e9
參考鏈接：https://segmentfault.com/a/1190000009048911
平時提交的變動信息是應該遵循 Angular 規范 的，標准格式為：
<類型>[可選的作用域]: <描述>
[可選的正文]
[可選的腳注]
提交說明包含了下面的結構化元素，以向類庫使用者表明其意圖：
- fix: 類型 為
fix的提交表示在代碼庫中修復了一個 bug（這和語義化版本中的PATCH相對應）。 - feat: 類型 為
feat的提交表示在代碼庫中新增了一個功能（這和語義化版本中的MINOR相對應）。 - BREAKING CHANGE: 在可選的正文或腳注的起始位置帶有
BREAKING CHANGE:的提交，表示引入了破壞性變更（這和語義化版本中的MAJOR相對應）。破壞性變更可以是任意 類型 提交的一部分。對於fix:、feat:和chore:，乃至更多其它的 類型 而言，它都是有效的。 - 其它在
fix:和feat:之外的提交 類型 也都是支持的，例如 Angular 約定 中推薦使用docs:、style:、refactor:、perf:、test:、chore:，但這些標簽在約定式提交規范中並不是強制性的。
其他標簽含義：
- docs：文檔（documentation）
- style： 格式（不影響代碼運行的變動）
- refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
- test：增加測試
- chore：構建過程或輔助工具的變動
約定式提交規范
本文檔中的關鍵詞 “必須”、“禁止”、“需要”、“應當”、“不應當”、“應該”、“不應該”、“推薦”、“可以” 和 “可選” 應按照 RFC 2119 的描述解釋。
- 每個提交都必須使用類型字段前綴，這由一個形如
feat或fix的名詞組成，其后接冒號和空格。 - 當一個提交為應用或類庫實現了新特性時，必須使用
feat類型。 - 當一個提交為應用修復了 bug 時，必須使用
fix類型。 - 可選的作用域字段可以在類型后提供。作用域是描述代碼庫中某個部分的詞組，封裝在括號中，形如
fix(parser):等。 - 描述字段必須緊接在類型或作用域前綴之后。描述指的是對代碼變更的簡短描述，形如 fix: array parsing issue when multiple spaces were contained in string.
- 在簡短描述之后，可以編寫更長的提交正文，為代碼變更提供額外的上下文信息。正文必須起始於描述字段結束的一個空行后。
- 在正文結束的一個空行后，可以編寫腳注（如果正文缺失，可以編寫在描述之后）。腳注應當為代碼變更包含額外的 issue 引用信息（例如它所修復的 issue，類似
Fixes #13等）。 - 破壞性變更必須在提交的正文或腳注加以展示。一個破壞性變更必須包含大寫的文本
BREAKING CHANGE，緊跟冒號和空格。 - 在
BREAKING CHANGE:之后必須提供描述，以描述對 API 的變更。例如 BREAKING CHANGE: environment variables now take precedence over config files. - 腳注必須只包含
BREAKING CHANGE、外部鏈接、issue 引用和其它元數據信息。 - 在提交說明中，可以使用
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