git原理--commit規範

一直是 ESLint 的忠實用戶，深知規範的重要性。然而，在新項目交接中，我被 Git Commit 規範逼瘋了。才意識到本身的疏忽，因而便有了一探究竟的想法。
關鍵詞：husky+@commitlint/cli ghooks+validate-commit-msg

原文連接 http://jartto.wang/2018/07/08/git-commit/。

1、爲何須要規範？

無規矩不成方圓，編程也同樣。

若是你有一個項目，從始至終都是本身寫，那麼你想怎麼寫均可以，沒有人能夠干預你。但是若是在團隊協做中，你們都張揚個性，那麼代碼將會是一團糟，好好的項目就被糟踐了。不論是開發仍是往後維護，都將是災難。

這時候，有人提出了何不統一標準，你們都按照這個標準來。因而 ESLint，JSHint 等代碼工具如雨後春筍般涌現，成爲了項目構建的必備良品。

Git Commit 規範可能並無那麼誇張，但若是你在版本回退的時候看到一大段糟心的 Commit，恐怕會懊惱不已吧。因此，嚴格遵照規範，利人利己。

2、具體規則

先來看看公式：

<type>(<scope>): <subject>

type

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

1. feat：新功能（feature）
2. fix：修補bug
3. docs：文檔（documentation）
4. style： 格式（不影響代碼運行的變更）
5. refactor：重構（即不是新增功能，也不是修改bug的代碼變更）
6. test：增長測試
7. chore：構建過程或輔助工具的變更
8. build: 本地creator構建

scope

用於說明 commit 影響的範圍，好比數據層、控制層、視圖層等等，視項目不一樣而不一樣。

subject

是 commit 目的的簡短描述，不超過50個字符。

1.以動詞開頭，使用第一人稱如今時，好比change，而不是changed或changes

2.第一個字母小寫

3.結尾不加句號（.）

規範參考自阮一峯老師的文章：Commit message 和 Change log 編寫指南。

3、異常處理

咱們先來看看這個異常提醒：

INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" !

jartto:fix bug

這裏之因此報出這個警告，是由於個人提交出現了兩個問題：

其一，使用了規範外的關鍵字；

其二，很細節的問題，jartto：後少了空格；

這時候我纔回憶起來，當時提交一直失敗，情急之下直接強制提交，因此之後的提交都會抱出這個異常。大體意思就是：

你的以前的 Commit 不合格～你的以前的 Commit 不合格～你的以前的 Commit 不合格

這時候就很煩了，咱們只能去將以前的錯誤修正，那麼如何操做呢？

4、如何修改以前的 commit 信息？

其實並不複雜，咱們只須要這樣作:

1. 將當前分支無關的工做狀態進行暫存

git stash

1. 將 HEAD 移動到須要修改的 commit 上

git rebase 9633cf0919^ --interactive

1. 找到須要修改的 commit ,將首行的 pick 改爲 edit
2. 開始着手解決你的 bug
3. git add 將改動文件添加到暫存
4. git commit –amend 追加改動到提交
5. git rebase –continue 移動 HEAD 回最新的 commit
6. 恢復以前的工做狀態

git stash pop

大功告成，是否是想把整個 Commit 都修改一遍，逃～

此處參考自：修改 Commit 日誌和內容

5、項目中使用

這時候問題又來了，爲何我提交的時候會有警告，這個又是如何作到的呢？

這時候，咱們須要一款 Node 插件 validate-commit-msg 來檢查項目中 Commit message 是否規範。

1.首先，安裝插件：

npm install --save-dev validate-commit-msg

2.使用方式一，創建 .vcmrc 文件：

{

  "types": ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert"],

  "scope": {

    "required": false,

    "allowed": ["*"],

    "validate": false,

    "multiple": false

  },

  "warnOnFail": false,

  "maxSubjectLength": 100,

  "subjectPattern": ".+",

  "subjectPatternErrorMsg": "subject does not match subject pattern!",

  "helpMessage": "",

  "autoFix": false

}

3.使用方式二：寫入 package.json

{

  "config": {

    "validate-commit-msg": {

      /* your config here */

    }

  }

}

4.但是咱們若是想自動使用 ghooks 鉤子函數呢？

{

  …

  "config": {

    "ghooks": {

      "pre-commit": "gulp lint",

      "commit-msg": "validate-commit-msg",

      "pre-push": "make test",

      "post-merge": "npm install",

      "post-rewrite": "npm install",

      …

    }

  }

  …

}

在 ghooks 中咱們能夠作不少事情，固然不僅是 validate-commit-msg 哦。

更多細節請參考：validate-commit-msg

6、Commit 規範的做用

1. 提供更多的信息，方便排查與回退；
2. 過濾關鍵字，迅速定位；
3. 方便生成文檔；

7、生成 Change log

正如上文提到的生成文檔，若是咱們的提交都按照規範的話，那就很簡單了。生成的文檔包括如下三個部分：

New features

Bug fixes

Breaking changes.

每一個部分都會羅列相關的 commit ，而且有指向這些 commit 的連接。固然，生成的文檔容許手動修改，因此發佈前，你還能夠添加其餘內容。

這裏須要使用工具 Conventional Changelog 生成 Change log ：

npm install -g conventional-changelog

cd jartto-domo

conventional-changelog -p angular -i CHANGELOG.md -w

爲了方便使用，能夠將其寫入 package.json 的 scripts 字段。

{

  "scripts": {

    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0"

  }

}

這樣，使用起來就很簡單了：

npm run changelog

到這裏，咱們全部的問題都搞明白了，Cheers～

8、總結

看完文章，你還會如此放蕩不羈嗎？你還會爲所欲爲的編寫 Commit 嗎？你還會如此 git commit -m "hello jartto"提交嗎？

答案是否認的，由於使用了鉤子函數，你沒有機會了，不然將是無窮無盡的恢復 Commit。這倒能夠養成良好的提交習慣，～

注意

在設置完git hooks以後 有使用sourceTree的同窗，可能會出現報錯；

這個報錯出現的緣由是由於 在sourceTree中的環境變量node找不到！sourceTree執行hooks文件和直接用命令行稍有不一樣不一樣。

打開 ./.git/hooks/ 能夠發現有不少hook文件，文件的頭部都有node環境標識 ---- #!/usr/bin/env node

報錯的根本緣由是 該標識的node 獲取不到

修改方法：

• 查看本機的node路徑

$ which node

# 個人路徑是 #!/usr/local/bin/node

將正確的node路徑放在 hooks下文件的頭部 做爲聲明便可；

• 本身修改hooks文件比較麻煩，夥伴直接難以同步
• 修改以後 sourceTree功能大多能使用 可是commit依然沒法正常使用
• 使用husky

使用husky+@commitlint/cli

husky和ghooks 都能實現對git中的hooks進行控制（在每一步git操做中增長鉤子），如圖所示

主要區別是文件頭的聲明方式不同：

ghooks 不兼容sourceTree

#!/usr/bin/env node

# ghooks

#!/bin/sh

# husky

安裝依賴：

npm i -D husyk @commitlint/cli

新建.commitlintrc.js 文件

module.exports = {

parserPreset: 'conventional-changelog-conventionalcommits',

rules: {

'body-leading-blank': [1, 'always'],

'footer-leading-blank': [1, 'always'],

'header-max-length': [2, 'always', 72],

'scope-case': [2, 'always', 'lower-case'],

'subject-case': [

2,

'never',

['sentence-case', 'start-case', 'pascal-case', 'upper-case']

],

'subject-empty': [2, 'never'],

'subject-full-stop': [2, 'never', '.'],

'type-case': [2, 'always', 'lower-case'],

'type-empty': [2, 'never'],

'type-enum': [

2,

'always',

[

'build',

'chore',

'docs',

'feat',

'fix',

'refactor',

'style',

'test'

]

]

}

};

配置package.json

"husky": {

"hooks": {

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

}

}

驗證commit

git commit -m 'aaa'

husky > commit-msg (node v8.11.3)

⧗  input: aaa

✖  subject may not be empty [subject-empty]

✖  type may not be empty [type-empty]

✖  found 2 problems, 0 warnings

ⓘ  Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

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

git commit -m 'feat: 驗證commitlint'

husky > commit-msg (node v8.11.3)

[test 1b4a515] feat: 驗證commitlint

1 file changed, 1 insertion(+), 1 deletion(-)

文章首發於 Jartto's blog ， 原文連接 http://jartto.wang/2018/07/08...。![!