每次提交代碼時熄浓,由于每個人的習(xí)慣不同,導(dǎo)致commit信息不明確,
所以工禾,為了能使得日后復(fù)(zhao)盤(guo)的時候更加的方便运提,團(tuán)隊(duì)之間遵守同一套 commit message 規(guī)范還是很有必要的。(轉(zhuǎn))
commit message 的作用
- 提供更多的歷史信息闻葵,方便快速瀏覽民泵。
- 可以過濾某些commit(比如文檔改動),便于快速查找信息槽畔。
- 可以直接從commit生成Change log栈妆。
定制 commit message規(guī)范
IDEA安裝插件 Git Commit Template
1、搜索commit message template并安裝竟痰,安裝完重啟
2签钩、提交代碼
- Header
Header的部分只有一行,包括三個字段: type(必需), scope(可選), subject(必需)
對應(yīng)到idea插件上圖的配置分別為 Header部分的:
type(必需) Type of change commit類別
scope(可選) Scope of this change commint影響的范圍
subject(必需) Short description 簡短的描述
(1)type用于說明 commit 的類別,只允許使用下面7個標(biāo)識
feat:新功能(feature)
fix:修補(bǔ)bug
docs:文檔(documentation)
style: 格式(不影響代碼運(yùn)行的變動,空格,格式化,等等)
refactor:重構(gòu)(即不是新增功能坏快,也不是修改bug的代碼變動)
perf: 性能 (提高代碼性能的改變)
test:增加測試或者修改測試
build: 影響構(gòu)建系統(tǒng)或外部依賴項(xiàng)的更改(maven,gradle,npm 等等)
ci: 對CI配置文件和腳本的更改
chore:對非 src 和 test 目錄的修改
revert: Revert a commit
(2) scope
scope用于說明 commit 影響的范圍铅檩,比如數(shù)據(jù)層、控制層莽鸿、視圖層等等昧旨,視項(xiàng)目不同而不同。
(3) subject
subject是 commit 目的的簡短描述祥得,不超過50個字符兔沃。
以動詞開頭,使用第一人稱現(xiàn)在時级及,比如change乒疏,而不是changed或changes
第一個字母小寫
結(jié)尾不加句號(.)
- Body
Body 部分是對本次 commit 的詳細(xì)描述,可以分成多行饮焦。
有兩個注意點(diǎn)怕吴。
(1)使用第一人稱現(xiàn)在時,比如使用change而不是changed或changes县踢。
(2)應(yīng)該說明代碼變動的動機(jī)转绷,以及與以前行為的對比。
- Footer
Footer 部分只用于兩種情況硼啤。
(1)不兼容變動
如果當(dāng)前代碼與上一個版本不兼容议经,則 Footer 部分以BREAKING CHANGE開頭,后面是對變動的描述谴返、以及變動理由和遷移方法煞肾。
BREAKING CHANGE: isolate scope bindings definition has changed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
}
After:
scope: {
myAttr: '@',
}
The removed `inject` wasn't generaly useful for directives so there should be no code using it.
(2)關(guān)閉 Issue
如果當(dāng)前 commit 針對某個issue,那么可以在 Footer 部分關(guān)閉這個 issue 嗓袱。
Closes #234
也可以一次關(guān)閉多個 issue 扯旷。
Closes #123, #245, #992
示例
commit規(guī)范已經(jīng)做完了,接下來就是要把所有的commit信息記錄在changelog里索抓。
1钧忽、commitizen安裝
cnpm install -g commitizen
會自動在項(xiàng)目根路徑生成package.json
2毯炮、安裝適配器
cnpm install cz-conventional-changelog --save-dev
commitizen 工具會自動在package.json中添加配置相應(yīng)的配置,具體如下:"config": {"commitizen": {"path": "cz-conventional-changelog"}}
3耸黑、安裝conventional-changelog-cli
cnpm install -g conventional-changelog-cli
基本使用
conventional-changelog -p angular -i CHANGELOG.md -s
以上命令中參數(shù)-p angular用來指定使用的 commit message 標(biāo)準(zhǔn)
參數(shù)-i CHANGELOG.md表示從 CHANGELOG.md 讀取 changelog, -s 表示讀寫 changelog 為同一文件桃煎。需要注意的是,上面這條命令產(chǎn)生的 changelog 是基于上次 tag 版本之后的變更(Feature大刊、Fix为迈、Breaking Changes等等)所產(chǎn)生的,所以如果你想生成之前所有 commit 信息產(chǎn)生的 changelog 則需要使用這條命令:$ conventional-changelog -p angular -i CHANGELOG.md -s -r 0其中 -r 表示生成 changelog 所需要使用的 release 版本數(shù)量缺菌,默認(rèn)為1葫辐,全部則是0。
那么 tag 版本是怎么指定的呢伴郁,請看package.json
{
"devDependencies": {
"commitizen": "^4.0.3",
"cz-conventional-changelog": "^3.0.2"
},
"config": {
"commitizen": {
"path": "./node_modules/cz-conventional-changelog"
}
},
"version": "1.0.2",
"scripts": {
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md"
}
}
version即是當(dāng)前版本號耿战,需要手動指定
那么如何生成changelog呢
changelog是記錄版本之間的變化
通常情況線下,我們會在 master 分支進(jìn)行如下的版本發(fā)布操作
- git pull origin master
- 根據(jù) pacakage.json 中的 version 更新版本號焊傅,更新 changelog
- git add -A, 然后 git commit
- git tag 打版本操作
- push 版本 tag 和 master 分支到倉庫
tag打完之后會有新的版本號剂陡,將此版本號更新到pacakage.json 中的 version字段,執(zhí)行
npm run changelog
之后changelog已經(jīng)有更新了狐胎,更新會自動分類