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