優雅的提交你的 Git Commit Message

時間 2019-11-05

標籤優雅提交 git commit message 欄目 Git 简体版

原文原文鏈接

題注：若是喜歡咱們的文章別忘了點擊關注阿里南京技術專刊呦~ 本文轉載自阿里南京技術專刊-知乎，歡迎大牛小牛投遞阿里南京前端/後端開發等職位，詳見阿里南京誠邀前端小夥伴加入~。css

commit message 是開發的平常操做, 寫好 log 不只有助於他人 review, 還能夠有效的輸出 CHANGELOG, 對項目的管理實際相當重要, 可是實際工做中卻經常被你們忽略. 但願經過本文, 可以幫助你們重視和規範 commit message 的書寫.前端

原由

知乎上有個問題: 如何寫好 Git commit log? 頗有意思, 能看到各類提交風格: 有用 emoji 的, 有用唐詩的, 有用隨機生成的. 風格沒有對錯, 只要可以體現出 commit 所作的修改便可.node

可是最讓我印象深入的是 @李華橋的答案:git

這種東西，固然要藉助工具了，纔可以寫得即規範，又格式化，還可以支持後續分析。目前比較建議的是，使用終端工具 commitizen/cz-cli + commitizen/cz-conventional-changelog + conventional-changelog/standard-version 一步解決提交信息和版本發佈。
甚至，若是想更狠一點，在持續集成裏面加入 marionebl/commitlint 檢查 commit 信息是否符合規範，也不是不能夠。github

本文就順着這個方向, 給你們介紹下如何保障項目 commit message 的規範和格式化.npm

Commit Message 格式

目前規範使用較多的是 Angular 團隊的規範, 繼而衍生了 Conventional Commits specification. 不少工具也是基於此規範, 它的 message 格式以下:json

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
複製代碼

咱們經過 git commit 命令帶出的 vim 界面填寫的最終結果應該相似如上這個結構, 大體分爲三個部分(使用空行分割):vim

標題行: 必填, 描述主要修改類型和內容
主題內容: 描述爲何修改, 作了什麼樣的修改, 以及開發的思路等等
頁腳註釋: 放 Breaking Changes 或 Closed Issues

分別由以下部分構成:後端

type: commit 的類型
feat: 新特性
fix: 修改問題
refactor: 代碼重構
docs: 文檔修改
style: 代碼格式修改, 注意不是 css 修改
test: 測試用例修改
chore: 其餘修改, 好比構建流程, 依賴管理.
scope: commit 影響的範圍, 好比: route, component, utils, build...
subject: commit 的概述, 建議符合 50/72 formatting
body: commit 具體修改內容, 能夠分爲多行, 建議符合 50/72 formatting
footer: 一些備註, 一般是 BREAKING CHANGE 或修復的 bug 的連接.

這樣一個符合規範的 commit message, 就好像是一份郵件.bash

git commit 模板

若是你只是我的的項目, 或者想嘗試一下這樣的規範格式, 那麼你能夠爲 git 設置 commit template, 每次 git commit 的時候在 vim 中帶出, 時刻提醒本身:

修改 ~/.gitconfig, 添加:

[commit]
template = ~/.gitmessage
複製代碼

新建 ~/.gitmessage 內容能夠以下:

# 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
#
複製代碼

Commitizen: 替代你的 git commit

咱們的目標仍是要經過工具生成和約束, 那麼如今就開始吧.

commitizen/cz-cli, 咱們須要藉助它提供的 git cz 命令替代咱們的 git commit 命令, 幫助咱們生成符合規範的 commit message.

除此以外, 咱們還須要爲 commitizen 指定一個 Adapter 好比: cz-conventional-changelog (一個符合 Angular團隊規範的 preset). 使得 commitizen 按照咱們指定的規範幫助咱們生成 commit message.

全局安裝

npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
複製代碼

主要, 全局模式下, 須要 ~/.czrc 配置文件, 爲 commitizen 指定 Adapter.

項目級安裝

npm install -D commitizen cz-conventional-changelog
複製代碼

package.json中配置:

"script": {
    ...,
    "commit": "git-cz",
},
 "config": {
    "commitizen": {
      "path": "node_modules/cz-conventional-changelog"
    }
  }
複製代碼

若是全局安裝過 commitizen, 那麼在對應的項目中執行 git cz or npm run commit 均可以.

效果以下:

自定義 Adapter

也許 Angular 的那套規範咱們不習慣, 那麼能夠經過指定 Adapter cz-customizable 指定一套符合本身團隊的規範.

全局或項目級別安裝:

npm i -g cz-customizable
or
npm i -D cz-customizable
複製代碼

修改 .czrc 或 package.json 中的 config 爲:

{ "path": "cz-customizable" }
or
  "config": {
    "commitizen": {
      "path": "node_modules/cz-customizable"
    }
  }
複製代碼

同時在~/ 或項目目錄下建立 .cz-config.js 文件, 維護你想要的格式: 好比個人配置文件: leohxj/.cz-config

效果以下:

Commitlint: 校驗你的 message

commitlint: 能夠幫助咱們 lint commit messages, 若是咱們提交的不符合指向的規範, 直接拒絕提交, 比較狠.

一樣的, 它也須要一份校驗的配置, 這裏推薦 @commitlint/config-conventional (符合 Angular團隊規範).

安裝:

npm i -D @commitlint/config-conventional @commitlint/cli
複製代碼

同時須要在項目目錄下建立配置文件 .commitlintrc.js, 寫入:

module.exports = {
  extends: [
    ''@commitlint/config-conventional''
  ],
  rules: {
  }
};
複製代碼

針對自定義的 Adapter 進行 Lint

若是你像我同樣, 使用的是自定義的 commitizen adapter, 那麼你須要:

npm i -D commitlint-config-cz @commitlint/cli
複製代碼

.commitlintrc.js 中寫入:

module.exports = {
  extends: [
    'cz'
  ],
  rules: {
  }
};
複製代碼

結合 Husky

校驗 commit message 的最佳方式是結合 git hook, 因此須要配合 Husky.

npm i husky@next
複製代碼

package.json 中添加:

"husky": {
    "hooks": {
      ...,
      "commit-msg": "commitlint -e $GIT_PARAMS"
    }
  },
複製代碼

效果以下:

standard-version: 自動生成 CHANGELOG

經過以上工具的幫助, 咱們的工程 commit message 應該是符合 Angular團隊那套, 這樣也便於咱們藉助 standard-version 這樣的工具, 自動生成 CHANGELOG, 甚至是語義化的版本號(Semantic Version).

安裝使用:

npm i -S standard-version
複製代碼

package.json 配置:

"scirpt": {
    ...,
    "release": "standard-version"
}
複製代碼

PS: standard-version 有不少其餘的特性, 這裏不過多涉及, 有興趣的同窗自行嘗試.

最後

commit message 的規範性很重要, 可是是否須要像本文這樣強制限制, 每一個團隊和我的都有本身的想法, 可是我的認爲: 好的習慣, 受益終身.

相關標籤/搜索

每日一句

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