求求你了！別瞎提交代碼了，看人家 Git 提交規範那叫一個舒服！

git 是現在市面上最流行的版本控制工具（圖文詳解 Git 工作原理），書寫良好的 commit message 能大大提高代碼維護的效率。但是在日常開發中由於缺少對於 commit message 的約束，導致填寫內容隨意、質量參差不齊，可讀性低亦難以維護。在項目中引入 commit message 規範已是迫在眉睫。

用什麼規範？

現在市面上比較流行的方案是約定式提交規範（Conventional Commits），它受到了 Angular 提交準則的啓發，並在很大程度上以其爲依據。約定式提交規範是一種基於提交消息的輕量級約定。它提供了一組用於創建清晰的提交歷史的簡單規則；這使得編寫基於規範的自動化工具變得更容易。這個約定與 SemVer 相吻合，在提交信息中描述新特性、bug 修復和破壞性變更。它的 message 格式如下:

<類型>[可選的作用域]: <描述>

[可選的正文]

[可選的腳註]

Quick Start

1. 全局安裝 commitizen & cz-conventional-changelog

commitizen 是一個撰寫合格 commit message 的工具，用於代替 git commit 指令，而 cz-conventional-changelog 適配器提供 conventional-changelog 標準（約定式提交標準）。基於不同需求，也可以使用不同適配器。全網最全的 Git 分支開發規範手冊

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

安裝完畢後，可直接使用 git cz 來取代 git commit。

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

2. 項目內安裝 commitlint & husky

commitlint 負責用於對 commit message 進行格式校驗，husky 負責提供更易用的 git hook。萬字詳解！Git 入門最佳實踐

Use npm
npm i -D husky @commitlint/config-conventional @commitlint/cli

Use yarn
yarn add husky @commitlint/config-conventional @commitlint/cli -D

commitlint 只能做格式規範，無法觸及內容。對於內容質量的把控只能靠我們自己。

3. 添加相應配置

創建 commitlint.config.js

# In the same path as package.json

echo 'module.exports = {extends: ["@commitlint/config-conventional"]};' > ./commitlint.config.js

引入husky

# package.json

...,
"husky": {
    "hooks": {
      "commit-msg": "commitlint -e $GIT_PARAMS"
    }
}
4. 使用

執行 git cz 進入 interactive 模式，根據提示依次填寫

1.Select the type of change that you're committing 選擇改動類型 (<type>)

2.What is the scope of this change (e.g. component or file name)? 填寫改動範圍 (<scope>)

3.Write a short, imperative tense description of the change: 寫一個精簡的描述 (<subject>)

4.Provide a longer description of the change: (press enter to skip) 對於改動寫一段長描述 (<body>)

5.Are there any breaking changes? (y/n) 是破壞性修改嗎？默認n (<footer>)

6.Does this change affect any openreve issues? (y/n) 改動修復了哪個問題？默認n (<footer>)

生成的 commit message 格式如下：

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

填寫完畢後，husky 會調用 commitlint 對 message 進行格式校驗，默認規定 type 及 subject 爲必填項。

任何 git commit 指令的 option 都能用在 git cz 指令上, 例如 git cz -a

Commit message 規範在 rrd-fe 落地使用情況

針對團隊目前使用的情況，我們討論後擬定了 commit message 每一部分的填寫規則。

1. type

type 爲必填項，用於指定 commit 的類型，約定了 feat、fix 兩個主要 type，以及 docs、style、build、refactor、revert 五個特殊 type，其餘 type 暫不使用。

# 主要type
feat:     增加新功能
fix:      修復bug

# 特殊type
docs:     只改動了文檔相關的內容
style:    不影響代碼含義的改動，例如去掉空格、改變縮進、增刪分號
build:    構造工具的或者外部依賴的改動，例如webpack，npm
refactor: 代碼重構時使用
revert:   執行git revert打印的message

# 暫不使用type
test:     添加測試或者修改現有測試
perf:     提高性能的改動
ci:       與CI（持續集成服務）有關的改動
chore:    不修改src或者test的其餘修改，例如構建過程或輔助工具的變動

當一次改動包括主要 type 與特殊 type 時，統一採用主要 type。

2. scope

scope 也爲必填項，用於描述改動的範圍，格式爲項目名 / 模塊名，例如：node-pc/common rrd-h5/activity，而 we-sdk 不需指定模塊名。如果一次 commit 修改多個模塊，建議拆分成多次 commit，以便更好追蹤和維護。

3. body

body 填寫詳細描述，主要描述改動之前的情況及修改動機，對於小的修改不作要求，但是重大需求、更新等必須添加 body 來作說明。

4. break changes

break changes 指明是否產生了破壞性修改，涉及 break changes 的改動必須指明該項，類似版本升級、接口參數減少、接口刪除、遷移等。

5. affect issues

affect issues 指明是否影響了某個問題。例如我們使用 jira 時，我們在 commit message 中可以填寫其影響的 JIRA_ID，若要開啓該功能需要先打通 jira 與 gitlab。參考文檔：docs.gitlab.com/ee/user/pro…

填寫方式例如：

re #JIRA_ID
fix #JIRA_ID

示例

如果你喜歡這篇文章，希望能動動小手點個在看與轉發支持一波。

人人貸大前端技術中心 

juejin.im/post/5d0b3f8c6fb9a07ec07fc5d0

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/VUzOwjLAhHcTEbA-EnQemQ

猜你喜歡