你可能會忽略的 Git 提交規(guī)范

規(guī)范是建立在程序開發(fā)者與程序閱讀者一個溝通的橋梁，是一個團隊必須要嚴格遵守的約定
——動力節(jié)點Java學(xué)院
一、為什么需要規(guī)范？

無規(guī)矩不成方圓，編程也一樣。

如果你有一個項目，從始至終都是自己寫，那么你想怎么寫都可以，沒有人可以干預(yù)你。可是如果在團隊協(xié)作中，大家都張揚個性，那么代碼將會是一團糟，好好的項目就被糟踐了。不管是開發(fā)還是日后維護，都將是災(zāi)難。
這時候，有人提出了何不統(tǒng)一標準，大家都按照這個標準來。于是 ESLint，JSHint 等代碼工具如雨后春筍般涌現(xiàn)，成為了項目構(gòu)建的必備良品。

Git Commit 規(guī)范可能并沒有那么夸張，但如果你在版本回退的時候看到一大段糟心的 Commit，恐怕會懊惱不已吧。所以，嚴格遵守規(guī)范，利人利己。

二、具體規(guī)則

先來看看公式：
?type

用于說明 commit 的類別，只允許使用下面7個標識。
?scope
用于說明 commit 影響的范圍，比如數(shù)據(jù)層、控制層、視圖層等等，視項目不同而不同。
?subject
是 commit 目的的簡短描述，不超過50個字符。
1.以動詞開頭，使用第一人稱現(xiàn)在時，比如change，而不是changed或changes
2.第一個字母小寫
3.結(jié)尾不加句號（.）
規(guī)范參考自阮一峰老師的文章：Commit message 和 Change log 編寫指南。

三、異常處理

我們先來看看這個異常提醒：
1.INVALID COMMIT MSG: does not match "(): " !
2.
3.jartto:fix bug

這里之所以報出這個警告，是因為我的提交出現(xiàn)了兩個問題：
其一，使用了規(guī)范外的關(guān)鍵字；
其二，很細節(jié)的問題，jartto：后少了空格；

這時候我才回憶起來，當時提交一直失敗，情急之下直接強制提交，所以以后的提交都會抱出這個異常。大致意思就是：
你的之前的 Commit 不合格～你的之前的 Commit 不合格～你的之前的 Commit 不合格

這時候就很煩了，我們只能去將之前的錯誤修正，那么如何操作呢？

四、如何修改之前的 commit 信息？

其實并不復(fù)雜，我們只需要這樣做:

1、將當前分支無關(guān)的工作狀態(tài)進行暫存
1.git stash

2、將 HEAD 移動到需要修改的 commit 上
1.git rebase 9633cf0919^ --interactive
3、找到需要修改的 commit ,將首行的 pick 改成 edit 4、開始著手解決你的 bug 5、 git add 將改動文件添加到暫存 6、 git commit –amend 追加改動到提交 7、git rebase –continue 移動 HEAD 回最新的 commit 8、恢復(fù)之前的工作狀態(tài)
1.git stash pop

大功告成，是不是想把整個 Commit 都修改一遍，逃～
此處參考自：修改 Commit 日志和內(nèi)容

五、項目中使用

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

這時候，我們需要一款 Node 插件 validate-commit-msg 來檢查項目中 Commit message 是否規(guī)范。

1.首先，安裝插件：
1.npm install --save-dev validate-commit-msg

2.使用方式一，建立 .vcmrc 文件：
1.{
2.“types”: [“feat”, “fix”, “docs”, “style”, “refactor”, “perf”, “test”, “build”, “ci”, “chore”, “revert”],
3.
4.“scope”: {
5.
6.“required”: false,
7.
8.“allowed”: ["*"],
9.
10.“validate”: false,
11.
12.“multiple”: false
13.
14.},
15.
16.“warnOnFail”: false,
17.
18.“maxSubjectLength”: 100,
19.
20.“subjectPattern”: “.+”,
21.
22.“subjectPatternErrorMsg”: “subject does not match subject pattern!”,
23.
24.“helpMessage”: “”,
25.
26.“autoFix”: false
27.
28.}
3.使用方式二：寫入 package.json
1.
{

3.“config”: {
4.
5.“validate-commit-msg”: {
6.
7./* your config here */
8.
9.}}
10.}
4.可是我們?nèi)绻胱詣邮褂?ghooks 鉤子函數(shù)呢？
1.{
2.…
3.
4.“config”: {
5.
6.“ghooks”: {
7.
8.“pre-commit”: “gulp lint”,
9.
10.“commit-msg”: “validate-commit-msg”,
11.
12.“pre-push”: “make test”,
13.
14.“post-merge”: “npm install”,
15.
16.“post-rewrite”: “npm install”,
17.
18.…
19.
20.}
21.
22.}
23.
24.…
25.
26.}

六、Commit 規(guī)范的作用

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

七、生成 Change log

正如上文提到的生成文檔，如果我們的提交都按照規(guī)范的話，那就很簡單了。生成的文檔包括以下三個部分：
?New features
?Bug fixes
?Breaking changes.

每個部分都會羅列相關(guān)的 commit ，并且有指向這些 commit 的鏈接。當然，生成的文檔允許手動修改，所以發(fā)布前，你還可以添加其他內(nèi)容。
這里需要使用工具 Conventional Changelog 生成 Change log ：
1.npm install -g conventional-changelog
2.
3.cd jartto-domo
4.
5.conventional-changelog -p angular -i CHANGELOG.md -w

為了方便使用，可以將其寫入 package.json 的 scripts 字段。
1.{
2.
3.“scripts”: {
4.
5.“changelog”: “conventional-changelog -p angular -i CHANGELOG.md -w -r 0”
6.
7.}
8.
9.}
這樣，使用起來就很簡單了：
1.npm run changelog
到這里，我們所有的問題都搞明白了，?Cheers～

八、總結(jié)

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

答案是否定的，因為使用了鉤子函數(shù)，你沒有機會了，否則將是無窮無盡的恢復(fù) Commit。這倒可以養(yǎng)成良好的提交習(xí)慣，?～

動力節(jié)點Java架構(gòu)師班深度剖析Java底層原理，熱門技術(shù)深入探討，前沿技術(shù)深入解讀，大項目實戰(zhàn)重構(gòu)，從0到1做架構(gòu)，從全局思維出發(fā)，帶你把控大型項目中別人忽略的重要細節(jié)節(jié)點，站在巨人肩膀上學(xué)習(xí)架構(gòu)師，帶你領(lǐng)會架構(gòu)師不一樣的視野

總結(jié)

以上是生活随笔為你收集整理的Git 提交规范-Java程序员收藏必备的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。