git的commit規范及強制校驗

 

1、背景

---

在多人協作項目中，如果代碼風格統一、代碼提交信息的說明准確，那么在后期協作以及Bug處理時會更加方便。

先來介紹本人公司采用的commit規范

Commit message格式

<type>: <subject>

注意冒號后面有空格。

type

用於說明 commit 的類別，只允許使用下面7個標識。

• feat：新功能（feature）
• fix：修補bug
• docs：文檔（documentation）
• style： 格式（不影響代碼運行的變動）
• refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
• test：增加測試
• chore：構建過程或輔助工具的變動

如果type為feat和fix，則該 commit 將肯定出現在 Change log 之中。

subject

subject是 commit 目的的簡短描述，不超過50個字符，且結尾不加句號（.）。

 

注意

type    和    subject 之前有個英文冒號以及個空格！

---

 

 

2.在本文章中，我會介紹怎么使用下面這個工具，在git push 代碼之前檢測commit messages：

1. commitlint        https://marionebl.github.io/commitlint/#/ 
2. husky              https://github.com/typicode/husky 

 

3、使用工具校驗commit是否符合規范

3.1 全局安裝(這步很重要)

npm install -g @commitlint/cli @commitlint/config-conventional


項目沒有package.json的話，要連忙 [npm | cnpm] init -y

 

 

 

4

 

 

 

 

 

1

npm install -g @commitlint/cli @commitlint/config-conventional

2

3

4

項目沒有package.json的話，要連忙 [npm | cnpm] init -y

 

 

3.2 生成配置配件

這個文件在根目錄下生成就可以了。

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

 

 

 

1

 

 

 

 

 

1

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

 

 

3.3 在commitlint.config.js制定提交message規范

"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']
  }
};

 

 

 

12

 

 

 

 

 

1

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

2

3

module.exports = {

4

  extends: ['@commitlint/config-conventional'],

5

  rules: {

6

    'type-enum': [2, 'always', [

7

      "feat", "fix", "docs", "style", "refactor", "test", "chore", "revert"

8

    ]],

9

    'subject-full-stop': [0, 'never'],

10

    'subject-case': [0, 'never']

11

  }

12

};

 

 

上面我們就完成了commitlint的安裝與提交規范的制定。檢驗commit message的最佳方式是結合git hook，所以需要配合Husky

 

3.4 husky介紹

---

husky繼承了Git下所有的鈎子，在觸發鈎子的時候，husky可以阻止不合法的commit,push等等。注意使用husky之前，必須先將代碼放到git 倉庫中，否則本地沒有.git文件，就沒有地方去繼承鈎子了。

npm install husky --save-dev

 

 

 

1

 

 

 

 

 

1

npm install husky --save-dev

 

 

安裝成功后需要在項目下的package.json中配置：

 

注意配置的最新，舊版本github把它的包干掉了，下載不了！

最新版本的配置（當前為v1.0.1版本，持續更新中）：
"husky": {
   "hooks": {
     "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  }



以下為0.14.3版本時的配置
"scripts": {
    "commitmsg": "commitlint -e $GIT_PARAMS",

 },
 "config": {
    "commitizen": {
      "path": "cz-customizable"
    }
  },

 

 

 

19

 

 

 

 

 

1

最新版本的配置（當前為v1.0.1版本，持續更新中）：

2

"husky": {

3

   "hooks": {

4

     "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"

5

    }

6

  }

7

8

9

10

以下為0.14.3版本時的配置

11

"scripts": {

12

    "commitmsg": "commitlint -e $GIT_PARAMS",

13

14

 },

15

 "config": {

16

    "commitizen": {

17

      "path": "cz-customizable"

18

    }

19

  },

 

 

最后我們可以正常的git操作

git add .

 

 

 

1

 

 

 

 

 

1

git add .

 

 

git commit的時候會觸發commlint。下面演示下不符合規范提交示例：

F:\accesscontrol\access_control>git commit -m "featdf: aas"
husky > npm run -s commitmsg (node v8.2.1)

⧗   input:
featdf: aas

✖   type must be one of [feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert] [type-enum]
✖   found 1 problems, 0 warnings

husky > commit-msg hook failed (add --no-verify to bypass)

F:\accesscontrol\access_control>

 

 

 

12

 

 

 

 

 

1

F:\accesscontrol\access_control>git commit -m "featdf: aas"

2

husky > npm run -s commitmsg (node v8.2.1)

3

4

⧗   input:

5

featdf: aas

6

7

✖   type must be one of [feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert] [type-enum]

8

✖   found 1 problems, 0 warnings

9

10

husky > commit-msg hook failed (add --no-verify to bypass)

11

12

F:\accesscontrol\access_control>

 

 

上面message不符合提交規范，所以會提示錯誤。

我們修改下type

F:\accesscontrol\access_control>git commit -m "feat: 新功能"
husky > npm run -s commitmsg (node v8.2.1)

⧗   input: feat: 新功能
✔   found 0 problems, 0 warnings

[develop 7a20657] feat: 新功能
 1 file changed, 1 insertion(+)

F:\accesscontrol\access_control>

 

 

 

10

 

 

 

 

 

1

F:\accesscontrol\access_control>git commit -m "feat: 新功能"

2

husky > npm run -s commitmsg (node v8.2.1)

3

4

⧗   input: feat: 新功能

5

✔   found 0 problems, 0 warnings

6

7

[develop 7a20657] feat: 新功能

8

 1 file changed, 1 insertion(+)

9

10

F:\accesscontrol\access_control>

 

 

commit成功。

 

3.5 husky的鈎子

可以在package.json下面添加如下的鈎子。

"husky": {
    "hooks": {
      "pre-commit": "npm run lint"
    }
  },

 

 

 

5

 

 

 

 

 

1

"husky": {

2

    "hooks": {

3

      "pre-commit": "npm run lint"

4

    }

5

  },

 

 

 

4、最后總結過程中遇到一些問題

1. git commit后可能報錯相關‘regenerator-runtime’模塊找不到；解決方式：npm install regenerator-runtime –save。
2. git commit -m “messge”,用雙引號
3. commit不上去，你先按這篇博客的步驟仔細檢查一下，是不是哪里順序錯了或者漏了。還出錯就去看看文章讓安裝的依賴是不是又更新了

 

文章原鏈接： https://blog.csdn.net/y491887095/article/details/80594043    （稍微補充了下本人踩的坑！）

<wiz_tmp_tag id="wiz-table-range-border" contenteditable="false" style="display: none;">