git commit message格式
- git每次提交代碼，都必須寫commit message(提交說明)寨腔，用來說明本次提交的目的凛辣，否則不允許提交。
git commit -m "hello world"
上面代碼的-m 參數(shù)听怕，就是用來指定commit message的捧挺。
- commit message的寫法規(guī)范有許多，本文介紹目前使用最廣的尿瞭，比較合理和系統(tǒng)化的一種規(guī)范：Angular 規(guī)范闽烙。
一、Commit message 格式
<type>(<scope>): <subject>
<空行>
<body>
<空行>
<footer>
其中声搁，Header 是必需的黑竞，Body 和 Footer 可以省略。
1.1 Header
Header部分只有一行疏旨，包括三個(gè)字段：type （必需)很魂、scope(可選)、subject（必需）
- type
type 用于說明commit的類別檐涝，允許使用以下7個(gè)標(biāo)識遏匆。
feat：新功能（feature）
fix：修補(bǔ)bug
docs：文檔（documentation）
style： 格式（不影響代碼運(yùn)行的變動）
refactor：重構(gòu)（即不是新增功能法挨，也不是修改bug的代碼變動）
test：增加測試
chore：構(gòu)建過程或輔助工具的變動
- scope
scope用于說明 commit 影響的范圍，比如數(shù)據(jù)層幅聘、控制層凡纳、視圖層等等，視項(xiàng)目不同而不同喊暖。
- subject
subject是 commit 目的的簡短描述惫企，不超過50個(gè)字符。
注意事項(xiàng)：
- 以動詞開頭陵叽，使用第一人稱現(xiàn)在時(shí)狞尔，比如change，而不是changed或changes
- 第一個(gè)字母小寫
- 結(jié)尾不加句號（.）
1.2 Body
Body 部分是對本次 commit 的詳細(xì)描述巩掺，可以分成多行偏序。(換行用\n)
1.3 Footer
Footer 部分只用于兩種情況。
- 不兼容變動
如果當(dāng)前代碼與上一個(gè)版本不兼容胖替，則 Footer 部分以BREAKING CHANGE開頭研儒，后面是對變動的描述、以及變動理由和遷移方法独令。
- 關(guān)閉Issue
如果當(dāng)前 commit 針對某個(gè)issue端朵，那么可以在 Footer 部分關(guān)閉這個(gè) issue。
Closes #234
也可以一次關(guān)閉多個(gè) issue 燃箭。
Closes #123, #245, #992
二冲呢、Commitizen
我們知道了提交規(guī)范，就需要通過工具生成和約束招狸。通過借助工具commitizen/cz-cli的安裝之后敬拓，就會產(chǎn)生規(guī)范性的提示語句，幫助我們形成規(guī)范的commit message裙戏。
Commitizen是一個(gè)撰寫合格 Commit message 的工具乘凸。
全局安裝，命令如下：
npm install -g commitizen cz-conventional-changelog
查看是否安裝成功
npm ls -g -depth=0
全局模式下, 需要 ~/.czrc 配置文件, 為 commitizen 指定 Adapter比如: cz-conventional-changelog (一個(gè)符合 Angular團(tuán)隊(duì)規(guī)范的 preset)累榜。
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
安裝成功后营勤，在對應(yīng)的git項(xiàng)目中，凡是用到git commit命令壹罚，一律改為使用git cz.這時(shí)冀偶，就會出現(xiàn)選項(xiàng)，用來生成符合格式的 Commit message渔嚷。
三进鸠、校驗(yàn)Commit message 是否符合規(guī)范
Commitlint
commitlint用于檢查我們的commit message是否符合提交規(guī)范，如果不符合形病，則直接拒絕提交客年。
全局安裝
npm install -g @commitlint/cli @commitlint/config-conventional
生成配置文件
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
你也可以在commitlint.config.js制定提交message規(guī)范
"module.exports = {extends: ['@commitlint/config-conventional']}"
module.exports = {
extends: ['@commitlint/config-conventional'],
rules: {
'type-enum': [2, 'always', [
"feat", "fix", "docs", "style", "refactor", "test", "chore", "revert"
]],
'subject-full-stop': [0, 'never'],
'subject-case': [0, 'never']
}
};
上面我們就完成了commitlint的安裝與提交規(guī)范的制定霞幅。但檢驗(yàn)commit message的最佳方式是結(jié)合git hook，所以需要配合Husky量瓜。
Husky
husky繼承了Git下所有的鉤子司恳，在觸發(fā)鉤子的時(shí)候，husky可以阻止不合法的commit,push等等绍傲。
創(chuàng)建package.json文件
進(jìn)入到git項(xiàng)目中扔傅，執(zhí)行
npm init --yes
會生成項(xiàng)目對應(yīng)項(xiàng)目的package.json
進(jìn)入項(xiàng)目中，安裝husky
npm install husky
安裝成功后需要在項(xiàng)目的package.json中配置：
"husky": {
"hooks": {
"commit-msg": "commitlint -e $GIT_PARAMS"
}
}
然后我們正常操作git
git add .
git commit -m "test"
上面message不符合提交規(guī)范烫饼，所以會報(bào)錯如下：
起到了校驗(yàn)的作用猎塞。
四、生成Change Log
如果你的所有 Commit 都符合 Angular 格式杠纵，那么發(fā)布新版本時(shí)荠耽， Change log 就可以用腳本自動生成
生成的文檔包括以下三個(gè)部分。
- New features
- Bug fixes
- Breaking changes
每個(gè)部分都會羅列相關(guān)的 commit 比藻，并且有指向這些 commit 的鏈接铝量。當(dāng)然，生成的文檔允許手動修改银亲，所以發(fā)布前慢叨，你還可以添加其他內(nèi)容。
conventional-changelog 就是生成 Change log 的工具务蝠。
安裝changelog
npm install -g conventional-changelog
npm install -g conventional-changelog-cli
進(jìn)入git項(xiàng)目目錄下拍谐，執(zhí)行命令：
conventional-changelog -p angular -i CHANGELOG.md -s
以上命令中參數(shù)-p angular用來指定使用的 commit message 標(biāo)準(zhǔn)為angular，參數(shù)-i CHANGELOG.md表示生成的 changelog輸出到 CHANGELOG.md 文件中请梢。
命令執(zhí)行完會在項(xiàng)目中生成CHANGELOG.md文件
注意：上面這條命令產(chǎn)生的 changelog 是基于上次 tag 版本(本地的tag版本)之后的變更（Feature、Fix力穗、Breaking Changes等等）所產(chǎn)生的毅弧，如果你想生成之前所有 commit 信息產(chǎn)生的 changelog 則需要使用這條命令：
conventional-changelog -p angular -i CHANGELOG.md -w -r 0
由于命令過長，可以在package.json中配置scripts
{
"scripts": {
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s"
}
}
以后当窗，直接運(yùn)行下面的命令即可够坐。
npm run changelog
standard-version 也是生成 Change log 的工具。
正常情況下兑巾，版本發(fā)布流程如下：
- git pull origin master
- 根據(jù) pacakage.json 中的 version 更新版本號刊苍，更新 changelog
- git add -A,然后git commit
- git tag打版本操作
- push版本tag和master分支到遠(yuǎn)程倉庫
conventional-changelog工具需要在手動修改了pacakage.json版本號浑槽，生成了changelog之后，手動commit及打tag庶香。但standard-version工具會自動完成2、3简识、4項(xiàng)的工作赶掖。如果再配合本地的shell腳本感猛，則可以自動的完成一系列的版本發(fā)布工作。
安裝(推薦全局安裝)
npm i -g standard-version
在package.json中配置：
"scirpt": {
...,
"release": "standard-version"
}
使用：
npm run release
最終會在git項(xiàng)目中生成CHANGELOG.md文件
跟conventional-changelog生成的文件差不多奢赂。
更詳細(xì)的用法：
--first-release, -f 第一次打版本
standard-version -f
生成與package.json中版本號一致的tag陪白。本地不能存在一樣版本號的tag。
--release-as, -r 指定版本號
默認(rèn)情況下膳灶，工具會自動根據(jù) 主版本（major）,次版本（ minor） or 修訂版（patch） 規(guī)則生成版本號咱士，例如如果你package.json 中的version 為 4.3.1, 那么執(zhí)行后版本號則是：4.4.0。
standard-version -r minor
查看生成的tag:自動生成v4.4.0
查看提交記錄：修改已經(jīng)自動提交
最后提交本地代碼與tag
git push origin master
git push origin --tags
會在github上看到提交記錄與tag轧钓。
也可以固定版本：
standard-version -r 5.0.0
standard-version -r 5.0.0-test
會生成v5.0.0和5.0.0-test版本
--prerelease, -p 預(yù)發(fā)版本命名
用來生成預(yù)發(fā)版本, 如果當(dāng)期的版本號是 4.4.0序厉，例如
standard-version -p
standard-version -p alpha
standard-version -p test
會生成v4.4.1-0、v4.4.1-alpha.0聋迎、v4.4.1-test.0脂矫。其中alpha、test代表預(yù)發(fā)布版本的名稱霉晕。
--tag-prefix, -t 版本 tag 前綴
默認(rèn)有一個(gè)前綴v,如果不想有任何前綴庭再，直接用-t即可。
當(dāng)前版本4.4.1
standard-version -t "stable-"
standard-version -t "test-"
生成：test-5.0.0牺堰、stable-5.1.0,其中 test是第一次作為前綴使用拄轻，所以會生成一個(gè)主版本。
綜合使用：
standard-version -t 'stable-' -r 6.1.0
生成 stable-6.1.0
--dry-run
standard-version --dry-run
此命令會在允許你在后臺查看將運(yùn)行哪些步驟伟葫，不會修改package.json恨搓、changlog，也不會提交任何代碼及生成tag筏养「В可以其他命令結(jié)合使用。
standard-version -r 9.0.0 --dry-run
可用于查看該命令是否滿足你的需求渐溶。
