大家日常中的項目有沒有使用規範的Commit message提交格式?
如果有,你們有沒有使用工具去保證整個團隊成員提交的格式信息符合規範?
看到我們團隊的同學平時使用Git提交代碼，對於Commit message並沒有特別在意，因此我寫了一篇文章如何寫好 Git commit messages 去推廣這個。
現在希望找到一個合適的工具在項目成員提交代碼的時候能夠做出保障，對於Commit message不符合規範的提交給予拒絕。
目前我發現有以下兩個NPM包質量和活躍度都還不錯：
https://www.npmjs.com/package/validate-commit-msg
https://www.npmjs.com/package/semantic-release
想在此調研一下，大家項目的使用情況如何？ 有沒有其它覺得更好的可以給予推薦的。
=============================
最後的方案參考：
Git commit message和工作流規範 希望能夠給需要的同學一個參考。
謝邀.
eggjs 團隊採用了開源社區常用的一套規範，參見『代碼貢獻規範 - 為企業級框架和應用而生 』。
優點是：- 清晰，直觀
- 我們的 changelog 可以直接通過指令生成
完整格式如下：
&
&
&
&
&
feat: all middleware support async function and common function
fix: deprecate warning when inspect toJSON, close #408
docs: add quickstart.md
我們之前曾有考慮過是否用工具來檢查，但後面並沒有引入，人是有惰性的，如果有工具幫他檢查了，他就不會進步了。
還有我們是通過 Pull Request 進行協作的，新人經過幾次的 code review 後，很快就會形成本能了，不會寫錯。（同例，參與 egg 之前我的 git 操作必須用 sourcetree，現在基本上只用命令行。）
當然，reviewer 如果沒注意，導致不對的 message 進入主幹，那需要準備好大洋請吃飯，別問我為什麼知道。
有興趣可以圍觀下我們的 commit message 和 pull request:- Commits · eggjs/egg · GitHub
- Pull Requests · eggjs/egg · GitHub
說下我目前的結論，供參考哈：
提交規範基本繼承angular.md conventional-changelog/angular.md at v0.5.3 · conventional-changelog/conventional-changelog · GitHub
使用commitizen，validate-commit-msg，配合使用husky(githooks)
commitizen是來規範格式的，validate-commit-msg配合husky來做commit message的格式校驗的。
另外，這個需要本地客戶端和git server hook一起搞哈~
下面是個參考例子：
{
"name": "commit-message-test",
"version": "0.0.1",
"scripts": {
"commitmsg": "validate-commit-msg",
"commit": "git-cz "
},
"devDependencies": {
"commitizen": "^2.3.0",
"validate-commit-msg": "^2.11.1",
"husky": "^0.13.1"
},
"config": {
"commitizen": {
"path": "cz-conventional-changelog"
}
}
}
我們的格式是：XXX-999 MESSAGE
XXX 是 JIRA 里的 project code；999 是 JIRA number；MESSAGE 不能夠為空，推薦直接 copy JIRA issue 的 Title。
pre-commit hook 會根據格式去檢查 JIRA 上的 issue 狀態，開發中和正確的分支才可以通過。否則拒絕。
用git hook來實現的
業界常用的標準： angular commit convention 工具：ghooks, commitizen等
給強迫症推薦一下：http://commitizen.github.io/cz-cli/
不準用 git commit -m
就行了。
用 git commit -v
別問為什麼。之前看@ @優達學城（Udacity） 納米學位課程時，有Instructor提供了一個Git Commit Message規範，在內部小組試用了一段時間，感覺還不錯。Udacity Nanodegree Style Guide 不過現在在糾結，內容要用中文還是英文。中文可能顯得不專業，但是英文的話，團隊成員英語水平不一致，有時會寫錯單詞。
用githook，但一定的要在本地遠程同時環境安裝，要不然會被折磨死，記得對版本有要求，而且ide環境通常有獨立的git，一定要切換到新版，要不然hook不生效。如果真的推，一定要逐個人確認，納入考核清單。
推薦閱讀：