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