你可能會忽略的 Git 提交規范
一直是 ESLint 的忠實用戶，深知規范的重要性。然而，在新項目交接中，我被 Git Commit 規范逼瘋了。才意識到自己的疏忽，于是便有了一探究竟的想法。
一、為什么需要規范？
無規矩不成方圓，編程也一樣。
如果你有一個項目，從始至終都是自己寫，那么你想怎么寫都可以，沒有人可以干預你。可是如果在團隊協作中，大家都張揚個性，那么代碼將會是一團糟，好好的項目就被糟踐了。不管是開發還是日后維護，都將是災難。
這時候，有人提出了何不統一標準，大家都按照這個標準來。于是 ESLint ， JSHint 等代碼工具如雨后春筍般涌現，成為了項目構建的必備良品。
Git Commit 規范可能并沒有那么夸張，但如果你在版本回退的時候看到一大段糟心的 Commit，恐怕會懊惱不已吧。所以，嚴格遵守規范，利人利己。
二、具體規則
先來看看公式：
- <type>(<scope>): <subject>
- type
- 用于說明 commit 的類別，只允許使用下面7個標識。
- feat：新功能（feature）
- fix：修補bug
- docs：文檔（documentation）
- style： 格式（不影響代碼運行的變動）
- refactor：重構（即不是新增功能，也不是修改bug的代碼變動）
- test：增加測試
- chore：構建過程或輔助工具的變動
- scope
- 用于說明 commit 影響的范圍，比如數據層、控制層、視圖層等等，視項目不同而不同。
- subject
- 是 commit 目的的簡短描述，不超過50個字符。
- 1. 以動詞開頭，使用***人稱現在時，比如change，而不是changed或changes
- 2. ***個字母小寫
- 3. 結尾不加句號（.）
規范參考自阮一峰老師的文章： Commit message 和 Change log 編寫指南 。
三、異常處理
我們先來看看這個異常提醒：
- 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
commit ,將首行的 pick 改成 edit 4、開始著手解決你的
bug 5、 git add 將改動文件添加到暫存
6、 git commit –amend 追加改動到提交
git rebase –continue 移動 HEAD 回***的 commit 8、恢復之前的工作狀態
- git stash pop
大功告成，是不是想把整個 Commit 都修改一遍，逃～
此處參考自： 修改 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.提供更多的信息，方便排查與回退；
2.過濾關鍵字，迅速定位；
3.方便生成文檔；
七、生成 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
到這里，我們所有的問題都搞明白了，:beers:Cheers～
八、總結
看完文章，你還會如此放蕩不羈嗎？你還會隨心所欲的編寫 Commit 嗎？你還會如此 git commit -m "hello jartto" 提交嗎？
答案是否定的，因為使用了鉤子函數，你沒有機會了，否則將是無窮無盡的恢復 Commit 。這倒可以養成良好的提交習慣，:see_no_evil:～
