git commit 、CHANGELOG 和版本發布的標准自動化

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

本文是一篇項目自動化方面的使用教程，社區里面針對四類問題的解決方案很多，今天這里主要介紹的是 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 給出了 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 

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

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