規範git commit提交記錄和版本發佈記錄

時間 2019-11-14

標籤規範 git commit 提交記錄版本發佈欄目 Git 简体版

原文原文鏈接

在開發過程當中咱們通常都會用到git管理代碼，在git commit提交代碼時咱們通常對git commit message隨便寫點簡單的描述，但是隨着項目參與人數的增多，發現提交的commit記錄愈來愈雜亂，不便查閱，在網上找了下解決方案，總結一下方便在公司項目中運用。前端

commit message 格式

目前你們比較承認的是Angular團隊的提交規範，不少工具也是基於此規範開發的。該提交規範格式以下:node

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

每個commit message由header（必填）、body（選填）和footer（選填）組成，header部分包括三個字段：type（必填）、scope（選填）和 subject（必填）。爲了方便瀏覽，每一行的commit message不該超過100個字符。git

type
type 用於說明提交的commit的類別，有一下幾種類型：github

feat：添加新功能（feature）
fix：改bug
docs：修改文檔（documentation）
style：只改樣式（不影響代碼運行的變更）
refactor：重構（即不是新增功能，也不是改bug的代碼變更）
perf : 代碼優化（提高代碼性能）
test：增長測試
chore：構建過程或輔助工具的變更

scope
本次改動影響的範圍
subject
對本次改動的簡單描述
body
commit 具體修改內容的詳細描述, 能夠分爲多行
footer
一些備註, 一般是 BREAKING CHANGE 或修復的 bug 的連接.npm

如何規範提交記錄

上面介紹的是通用的git commit message規範，但是在git commit的時候如何用這寫規範來寫呢？json

若是是我的項目咱們能夠爲 git 設置 commit template, 每次 git commit 的時候在 vim 中自動帶上模板信息, 本身只要按照模板信息填寫就行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編輯會帶上這些信息segmentfault

若是咱們的項目是多人蔘與的項目，這樣就不合適了。這裏咱們推薦使用cz-customizable工具生成和約束commit message
cz-customizable有兩種使用方式，這裏咱們採用官方推薦的第二種方式app

安裝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
};

該文件的配置信息可參考optionside

至此咱們在提交代碼時不在使用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連接不完整，小編就犯過這個錯

參考文章

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。