天天看點
傳回

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 commit 、CHANGELOG 和版本釋出的标準自動化

可以看到，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

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

git commit 、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

作者：Ziv小威

出處：http://imziv.com/

關于作者：專注于Java技術的程式員一枚，此外對JS開發保持着較高的興趣。愛好音樂，閱讀，FM等等。

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接配接。

如有問題，可以郵件：[email protected]

微網誌：Ziv小威

git 前端工程 自動化
上一篇: 金融企業架構
下一篇: 項目進階 之 持續建構環境搭建（一）架構