一直以來，因為團隊項目迭代節奏很快，每次發佈的更新日誌和版本更新都是通過人肉來完成的。有時候實在忙的團團轉，對於手動的寫這些更新信息就顯得力不從心了。對於團隊新來的小伙伴，有時候遇到些緊急情況，就更顯的亂糟糟，還是得麻煩團隊資深的同學。顯然這些工作，用自動化工具再適合不過了。本文是一篇項目自動化方 ...

一直以來，因為團隊項目迭代節奏很快，每次發佈的更新日誌和版本更新都是通過人肉來完成的。有時候實在忙的團團轉，對於手動的寫這些更新信息就顯得力不從心了。對於團隊新來的小伙伴，有時候遇到些緊急情況，就更顯的亂糟糟，還是得麻煩團隊資深的同學。顯然這些工作，用自動化工具再適合不過了。

本文是一篇項目自動化方面的使用教程，社區裡面針對四類問題的解決方案很多，今天這裡主要介紹的是 onventional-changelog 方案相關的內容。如果你正在思考或者試圖解決這方面的問題的話，不妨瞭解一下。

conventional-changelog

conventional-changelog 是一款可以根據項目的commit 和 metadata信息自動生成 changelogs 和 release notes的系列工具，並且在輔助 standard-version 工具的情況下，可以自動幫你完成生成version、打tag, 生成CHANGELOG等系列過程。

conventional-changelog 生態主要模塊

conventional-changelog-cli - conventional-changelog 核心命令行工具
standard-changelog - 針對 angular commit 格式的命令行工具
conventional-github-releaser - 利用 git metadata 針對 Github 的發佈工具
conventional-commits-detector - commit message 規範引用檢測
commitizen - 針對開發者簡單的 commit 規範
commitlint - commit Lint 工具

以上是 onventional-changelog 生態重要的幾個主要模塊，實際工作中這幾個工具常常是配套使用的，當然也需要根據自己的情況而定。篇幅有限，今天我們就主要介紹 commitizen、conventional-changelog-cli 、standard-version 這三工具了。

commitizen

commitizen 是一款標準化 git commit 信息的工具。在沒有規範的情況下，開發人員的 commit 信息是常常是隨意的，這就導致 commit 信息顯的很無用。可是當你在做git log、code review、編寫changelog等情況時，良好的 commit 規範就顯的尤為重要。

commitizen 安裝

$ npm install -g commitizen
# 或者本地安裝
$ npm install --save-dev commitizen

安裝適配器（Adapter)

因為不同的項目本身的構建方式的不同，commitizen 支持不同適配器的擴展，從而去滿足不同的構建需求的。本文主要使用cz-conventional-changelog的構建標準，當然你也可以根據具體的情況選擇其他的適配器，更多請看。

$ npm install -g cz-conventional-changelog

全局安裝完成後，我們需要在項目根目錄下添加 .czrc 配置文件，文件內容如下：

// path 用來指定適配器
{ "path": "cz-conventional-changelog" }

本地安裝

$ npm install cz-conventional-changelog --save-dev
# 或者使用 commitizen 工具
$ commitizen init cz-conventional-changelog --save-dev --save-exact

commitizen 工具會自動在package.json中添加配置相應的配置，具體如下：

  "config": {
    "commitizen": {
      "path": "cz-conventional-changelog"
    }
  }

安裝並添加完後，我們便可以使用 git cz 命令替換 git commit 來使用了。我們修改一個文件並 git add 後，通過 git cz 試一下：

git-cz

可以看到，git cz 給出了 commit 的幾種類型選項，如下：

feat 新功能
fix Bug 修複
docs 文檔更新
style 代碼的格式，標點符號的更新
refactor 代碼重構
perf 性能優化
test 測試更新
build 構建系統或者包依賴更新
ci CI 配置，腳本文件等更新
chore 非 src 或者測試文件的更新
revert commit 回退

使用的時候，我們應該根據項目具體變更情況選擇。如果想修改已經打好的 commit 信息，我們可以通過 git reset命令來修複。

需要註意的是，僅僅是添加 commit 工具是不夠的，為了保證 commit 格式的一致性，這裡強烈建議你記得整合 commitlint 工具, 配合 git commit-msg hook 來使用，在這裡就不相信介紹了，具體可以查看官方文檔。

conventional-changelog-cli

conventional-changelog-cli 預設推薦的 commit 標準是來自angular項目,除了 angular 標準以外，目前集成了包括 atom, codemirror, ember, eslint, express, jquery 等項目的標準，具體可以根據自己口味來選用。

安裝

# Help conventional-changelog --help
$ npm install -g conventional-changelog-cli

基本使用

$ conventional-changelog -p angular -i CHANGELOG.md -s

以上命令中參數-p angular用來指定使用的 commit message 標準，假如想使用atom的標準，則是：

$ conventional-changelog -p atom -i CHANGELOG.md -s

參數-i CHANGELOG.md表示從 CHANGELOG.md 讀取 changelog, -s 表示讀寫 changelog 為同一文件。需要註意的是，上面這條命令產生的 changelog 是基於上次 tag 版本之後的變更（Feature、Fix、Breaking Changes等等）所產生的，所以如果你想生成之前所有 commit 信息產生的 changelog 則需要使用這條命令：

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

其中 -r 表示生成 changelog 所需要使用的 release 版本數量，預設為1，全部則是0。

自定義參數

生成的 changlog 中有些常用內容可以通過自定義參數來根據需求更改，例如版本號、commit 地址等等。 changelog 中生成的版本號即是從 package.json 中獲取 version 欄位來的。commit 連接的倉庫地址我們需要修改 package.json 中的repository地址，changelog 中 issuse 預設的連接地址也是根據 repository 來生成的。如果你使用了第三方的協作系統（例如 bitbucket），那麼你可以使用這個標準conventional-changelog-angular-bitbucket。或者像我們使用 redmine 來管理 isssue ，那麼在生成 changelog 後可以使用 replace 工具來處理文本中的原有地址：

$ replace 'https://github.com/myproject/issues/' 'https://redmine.example.com' CHANGELOG.md

最後看看大致生成的效果：

changelog

conventional-changelog 更多的選項配置可以看這裡。

standard-version

standard-version 是一款遵循語義化版本（ semver）和 commit message 標準規範的版本和 changlog 自動化工具。通常情況線下，我們會在 master 分支進行如下的版本發佈操作：

1. git pull origin master
2. 根據 pacakage.json 中的 version 更新版本號，更新 changelog
3. git add -A, 然後 git commit
4. git tag 打版本操作
5. push 版本 tag 和 master 分支到倉庫

其中2，3，4則是 standard-version 工具會自動完成的工作，配合本地的 shell 腳本，則可以自動完成一系列版本發佈的工作了。

安裝 & 使用

在這裡我仍然推薦的全局安裝：

$ npm install -g standard-version
# 或者
$ npm install --save-dev standard-version

執行：

# Help standard-version --help
$ standard-version

執行 standard-version 命令，我們會在控制台看到整個執行流程的 log 信息，在這裡幾個常用的參數需要註意下:

--release-as, -r 指定版本號

預設情況下，工具會自動根據主版本（major）,次版本（ minor） or 修訂版（patch）規則生成版本號，例如如果你package.json 中的version 為 1.0.0, 那麼執行後版本號則是：1.0.1。自定義可以通過：

$ standard-version -r minor
# output 1.1.0
$ standard-version -r 2.0.0
# output 2.0.0
$ standard-version -r 2.0.0-test
# output 2.0.0-test

需要註意的是，這裡的版本名稱不是隨便的字元，而是需要遵循語義化版本（ semver）規範的

--prerelease, -p 預發版本命名

用來生成預發版本, 如果當期的版本號是 2.0.0，例如

$ standard-version --prerelease alpha
# output 2.0.0-alpha.0

--tag-prefix, -t 版本 tag 首碼

用來給生成 tag 標簽添加首碼，例如如果前版本號為 2.0.0，則：

$ standard-version --tag-prefix "stable-"
# output tag: stable-v2.0.0

以上這幾個參數可能我們用的比較多，還有其他選項可以通過 standard-version --help查看。

集成 npm

最後記得把命令集成到 npm package.json的 scripts 中, 並配合 shell 腳本使用, 如下：

"scripts": {
    "release": "./scripts/release.sh",
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md && npm run changeissueurl",
    "changeissueurl": "replace 'https://github.com/myproject/issues/' 'https://redmine.example.com/' CHANGELOG.md"
  },
  
// 配置好後使用 npm run 執行發佈
$ npm run release

添加 release.sh 腳本：

#!/bin/bash

# Release branch
master="master"
prefix="DTinsight_v"

git pull origin $master
echo "Current pull origin $master."

# Auto generate version number and tag
standard-version -r $release --tag-prefix $prefix

git push --follow-tags origin $master

echo "Git push origin $master"
echo "Release finished."

上面的腳本只是做了簡單的分支 pull, 執行 standard-version 和最後的版本 push 工作，如果要做一些定製化的執行參數，則需要做定製修改了。

最後

項目的工程化是一件很有意思的事情，通過自動化的工具，可以有效提升項目可維護性和質量，並且避免很多不確定因素。如果你工作中發現了這些問題，而不想繼續通過人肉的方法解決這些問題的話，那就趕緊試試~

原文地址：http://imziv.com/blog/article/index.htm

git commit 、CHANGELOG 和版本發佈的標準自動化