git commit的規範
https://www.yuque.com/fe9/basic/nruxq8#6c228def
制定一個 git commit 信息的提交規範是開發團隊工作流必不可少的環節。試想一下，如果查看主分支上的歷史庫也就是你查看 git log 的時候，打印出來的信息雜亂無章的話，如果代碼遇到問題，可能需要很大的精力與成本來查找到導致問題的代碼提交，所以團隊需要制定規範來引導成員編寫規範的 commit 信息。
接下來的 commit 信息規範參考了 angularjs 團隊的開發者指引與筆者的工作團隊進行總結，讀者如有需要可以以此為基礎增加或修改成為自己團隊的 commit 規範的一部分。
提交信息基本模板
如果 commit 信息都按照一定的模式進行提交，那麽我們就會很容易找到自己想要的信息，模板參考如下：
<type>(<scope>): <subject> [<ISSUE_ID>] <body> <footer>
commit 信息包括三個字段: type (必需)， scope(可選) 和 subject(必需)。
- type。type 是用於說明該 commit 的類型的，一般我們會規定 type 的類型如下：
- feat: 新功能(feature)
- fix: 修復 bug
- docs: 文檔(documents)
- style: 代碼格式(不影響代碼運行的格式變動，註意不是指 CSS 的修改)
- refactor: 重構(既不是新增功能，也不是修改 bug 的代碼變動)
- test: 提交測試代碼(單元測試，集成測試等)
- chore: 構建或輔助工具的變動
- misc: 一些未歸類或不知道將它歸類到什麽方面的提交
- scope。scope 說明 commit 影響的範圍，比如數據層，控制層，視圖層等等，這個需要視具體場景與項目的不同而靈活變動
- subject。subject 是對於該 commit 目的的簡短描述
- 使用第一人稱現在時的動詞開頭，比如 modify 而不是 modified 或 modifies
- 首字母小寫，並且結尾不加句號
- ISSUEE_ID。這個與公司的需求管理與項目管理有關，假設你的項目放在 github 上，你的需求或者 bug 修復可能會有對應的 issues 記錄，你可以加到你的 commit 信息中如 issue-37938634。
body 其實就是 subject 的詳細說明，而 footer 中你可以填寫相關的需求管理 issues id。
在企業中一般會對團隊中要做的事情與需求開發使用一個軟件進行管理，好處是可以讓代碼與對應的用戶故事(story)或者需求，bug 進行關聯，便於管理，類似的方案有 github，gitlab，tracker，JIRA 等等，比如在網易某些團隊中就會使用 JIRA 加上 gitlab 來進行團隊管理。
commit message 的規範性是很重要的，對於自己養成良好的編程習慣很有幫助，但是沒有必要強制完全遵循開源團隊的規範，畢竟每個團隊與個人的情況不同，博采眾長即可，當然你也可以使用像 commitlint 這樣的校驗工具從工具層面上來強制執行某些規範，這裏就不展開講了，有興趣的讀者可以查閱相關資料並使用到自己團隊的實踐中。
git commit的規範