Git提交規范是什么

本篇內容介紹了“Git提交規范是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

一、為什么需要規范?

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

如果你有一個項目，從始至終都是自己寫，那么你想怎么寫都可以，沒有人可以干預你。可是如果在團隊協作中，大家都張揚個性，那么代碼將會是一團糟，好好的項目就被糟踐了。不管是開發還是日后維護，都將是災難。

這時候，有人提出了何不統一標準，大家都按照這個標準來。于是 ESLint，JSHint 等代碼工具如雨后春筍般涌現，成為了項目構建的必備良品。

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

二、具體規則

先來看看公式：

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

type

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

• feat：新功能(feature)

• fix：修補

• bugdocs：文檔(documentation)

• style：  格式(不影響代碼運行的變動)

• refactor：重構(即不是新增功能，也不是修改bug的代碼變動)

• test：增加測試

• chore：構建過程或輔助工具的變動

scope

用于說明 commit 影響的范圍，比如數據層、控制層、視圖層等等，視項目不同而不同。

subject

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

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 以動詞開頭，使用***人稱現在時，比如change，而不是changed或changes

3. ***個字母小寫

4. 結尾不加句號(.)

三、異常處理

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

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

這里之所以報出這個警告，是因為我的提交出現了兩個問題：

• 其一，使用了規范外的關鍵字;

• 其二，很細節的問題，jartto：后少了空格;

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

• 你的之前的 Commit 不合格～你的之前的 Commit 不合格～你的之前的 Commit 不合格

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

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

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

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

git stash

2、將 HEAD 移動到需要修改的 commit 上

git rebase 9633cf0919^ --interactive

3、找到需要修改的 commit ,將首行的 pick 改成 edit

4、開始著手解決你的 bug

5、 git add 將改動文件添加到暫存

6、 git commit –amend 追加改動到提交

7、git rebase –continue 移動 HEAD 回***的 commit

8、恢復之前的工作狀態

git stash pop

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

五、項目中使用

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

這時候，我們需要一款 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

六、Commit 規范的作用

1. 鴻蒙官方戰略合作共建——HarmonyOS技術社區

2. 提供更多的信息，方便排查與回退;

3. 過濾關鍵字，迅速定位;

4. 方便生成文檔;

七、生成 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

“Git提交規范是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！