在開發過程中我們一般都會用到git管理代碼，在git commit提交代碼時我們一般對git commit message隨便寫點簡單的描述，可是隨着項目參與人數的增多，發現提交的commit記錄越來越雜亂，不便查閱，在網上找了下解決方案，總結一下方便在公司項目中運用。
commit message 格式
目前大家比較認可的是Angular團隊的提交規范，很多工具也是基於此規范開發的。該提交規范格式如下:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
每一個commit message由header（必填）、body（選填）和footer（選填）組成，header部分包括三個字段：type（必填）、scope（選填）和 subject（必填）。為了方便瀏覽，每一行的commit message不應超過100個字符。
type
type 用於說明提交的commit的類別，有一下幾種類型：
- feat：添加新功能（feature）
- fix：改bug
- docs： 修改文檔（documentation）
- style： 只改樣式（不影響代碼運行的變動）
- refactor：重構（即不是新增功能，也不是改bug的代碼變動）
- perf : 代碼優化（提升代碼性能）
- test：增加測試
- chore：構建過程或輔助工具的變動
scope
本次改動影響的范圍
subject
對本次改動的簡單描述
body
commit 具體修改內容的詳細描述, 可以分為多行
footer
一些備注, 通常是 BREAKING CHANGE 或修復的 bug 的鏈接.
如何規范提交記錄
上面介紹的是通用的git commit message規范，可是在git commit的時候如何用這寫規范來寫呢？
如果是個人項目我們可以為 git 設置 commit template, 每次 git commit 的時候在 vim 中自動帶上模板信息, 自己只要按照模板信息填寫就行
- 修改~/.gitconfig(.git/config文件), 添加:
[commit]
template = .git_template
- 新建.git_template 內容可如下：
# head: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer:
# - Include a link to the ticket, if any.
# - BREAKING CHANGE
#
這樣在項目中執行git commit時vim編輯會帶上這些信息
如果我們的項目是多人參與的項目，這樣就不合適了。這里我們推薦使用cz-customizable工具生成和約束commit message
cz-customizable有兩種使用方式，這里我們采用官方推薦的第二種方式
- 安裝cz-customizable
npm install cz-customizable --save-dev
- 修改package.json文件，在scripts中加入commit命令
"scripts" : {
...
"commit": "./node_modules/cz-customizable/standalone.js"
}
- 新建.cz-config.js文件
module.exports = {
types: [
{ value: 'feat', name: 'feat: A new feature' },
{ value: 'fix', name: 'fix: A bug fix' },
{ value: 'docs', name: 'docs: Documentation only changes' },
{
value: 'style',
name: 'style: Changes that do not affect the meaning of the code\n (white-space, formatting, missing semi-colons, etc)',
},
{
value: 'refactor',
name: 'refactor: A code change that neither fixes a bug nor adds a feature',
},
{
value: 'perf',
name: 'perf: A code change that improves performance',
},
{ value: 'test', name: 'test: Adding missing tests' },
{
value: 'chore',
name:'chore: Changes to the build process or auxiliary tools\n and libraries such as documentation generation',
}
],
scopes: [{ name: ''common }, { name: 'route' }, { name: 'components' }],
allowTicketNumber: false,
isTicketNumberRequired: false,
ticketNumberPrefix: 'TICKET-',
ticketNumberRegExp: '\\d{1,5}',
// it needs to match the value for field type. Eg.: 'fix'
/*
scopeOverrides: {
fix: [
{name: 'merge'},
{name: 'style'},
{name: 'e2eTest'},
{name: 'unitTest'}
]
},
*/
// override the messages, defaults are as follows
messages: {
type: "Select the type of change that you're committing:",
scope: '\nDenote the SCOPE of this change (optional):',
// used if allowCustomScopes is true
customScope: 'Denote the SCOPE of this change:',
subject: 'Write a SHORT, IMPERATIVE tense description of the change:\n',
body: 'Provide a LONGER description of the change (optional). Use "|" to break new line:\n',
breaking: 'List any BREAKING CHANGES (optional):\n',
footer: 'List any ISSUES CLOSED by this change (optional). E.g.: #31, #34:\n',
confirmCommit: 'Are you sure you want to proceed with the commit above?',
},
allowCustomScopes: true,
allowBreakingChanges: ['feat', 'fix'],
// skip any questions you want
skipQuestions: ['body','breaking','footer'],
// limit subject length
subjectLimit: 100,
// breaklineChar: '|', // It is supported for fields body and footer.
// footerPrefix : 'ISSUES CLOSED:'
// askForBreakingChangeFirst : true, // default is false
};
該文件的配置信息可參考options
至此我們在提交代碼時不在使用git commit命令，而是使用npm run commit這樣就可以按照規范輸出commit message。
校驗commit message
上面的配置中我們並沒有對commit message進行校驗，也就是說如果項目中有成員繼續使用git commit -m "message"提交仍是可以的，如果想增加commit message校驗可以使用validate-commit-msg工具
- 安裝相關依賴包
npm install validate-commit-msg husky --save-dev
- 在package.json文件中增加以下配置
"husky": {
"hooks": {
"commit-msg": "validate-commit-msg"
}
}
這樣我們團隊中如果有成員使用git commit -m 'message'提交時，會提交不通過的提示
$ git commit -m 'aaa'
husky > commit-msg (node v8.11.3)
INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" !
aaa
husky > commit-msg hook failed (add --no-verify to bypass)
至此用cz-customizable規范git commit提交記錄配置完成
記錄版本發布
在之前的前端開發腳手架項目改動時，我們總是手動編寫README文件，將做出的哪些改變一一列出來方便團隊成員瀏覽知曉，后來在網上查閱參考別的項目得知我們可以通過
standard-version工具自動生成CHANGLOG文件記錄版本變動
- 安裝
npm install standard-version --save-dev
- 修改package.json文件，在scripts中加入release命令
"scripts": {
...
"release": "standard-version"
},
執行npm run release即可生成CHANGELOG文件，該文件中包含Features和Bug Fixes的提交記錄
standard-version命令參數介紹
--release-as, -r Specify the release type manually (like npm version <major|minor|patch|1.1.0>) [字符串]
// major: 1.0.0 -> 2.0.0, minor: 1.0.0 -> 1.1.0, patch : 1.0.0 -> 1.0.1
--prerelease, -p make a pre-release with optional option value to specify a tag id [字符串]
--infile, -i Read the CHANGELOG from this file [默認值: "CHANGELOG.md"]
--message, -m Commit message, replaces %s with new version [字符串] [默認值: "chore(release): %s"]
--first-release, -f Is this the first release? [布爾] [默認值: false]
--sign, -s Should the git commit and tag be signed? [布爾] [默認值: false]
--no-verify, -n Bypass pre-commit or commit-msg git hooks during the commit phase [布爾] [默認值: false]
--commit-all, -a Commit all staged changes, not just files affected by standard-version [布爾] [默認值: false]
--silent Don't print logs and errors [布爾] [默認值: false]
--tag-prefix, -t Set a custom prefix for the git tag to be created [字符串] [默認值: "v"]
--scripts Provide scripts to execute for lifecycle events (prebump, precommit, [默認值: {}]
--skip Map of steps in the release process that should be skipped [默認值: {}]
--dry-run See the commands that running standard-version would run [布爾] [默認值: false]
// 第一次發布版本
npm run release -f
// 指定發布版本等級
npm run release -r minor
注意
使用standard-version生成CHANGELOG之前需要有完整的package.json文件，特別是有
"repository": {
"type": "git",
"url": "***"
}
否則生成的compare鏈接不完整，小編就犯過這個錯
參考文章