作者：程柳鋒
任何軟體項目都是一個協作項目，它至少需要2個開發人員參與，當原始的開發人員将項目開發幾個星期或者幾個月之後，項目步入正規。不過他們或者後續的開發人員仍然需要經常送出一些代碼去修複bug或者實作新的feature。我們經常有這種感受：當一個項目時間過了很久之後，我們對于項目裡面的檔案和函數功能漸漸淡忘，重新去閱讀熟悉這部分代碼是很浪費時間并且惱人的一件事。但是這也沒法完全避免，我們可以使用一些技巧盡可能減少重新熟悉代碼的時間。commit messages可以滿足需要，它也反映了一個開發人員是否是良好的協作者。
編寫良好的Commit messages可以達到3個重要的目的：
加快review的流程
幫助我們編寫良好的版本釋出日志
讓之後的維護者了解代碼裡出現特定變化和feature被添加的原因
先來看看一個比較好的例子，感受一下：
下面談談，如何讓項目裡面的Commit messages步入規範化，流程化。
Type表示送出類别，Subject表示标題行， Body表示主體描述内容。
Type的類别說明：
feat: 添加新特性
fix: 修複bug
docs: 僅僅修改了文檔
style: 僅僅修改了空格、格式縮進、都好等等，不改變代碼邏輯
refactor: 代碼重構，沒有加新功能或者修複bug
perf: 增加代碼進行性能測試
test: 增加測試用例
chore: 改變建構流程、或者增加依賴庫、工具等
這3個問題給代碼的變更建立了良好的上下文，可以讓其他的代碼review人員或者項目成員直覺的判斷修改點是否正确。一條良好的commit message也可以讓維護者知道這個patch是否适合釋出到穩定的版本中去。
如果一個patch沒有回答上面的這幾個問題，那麼它是無意義的。它會給review的人員造成負擔，讓他們花費大量時間去評審讨論這個patch的作用和意義。更糟糕的是，如果一個項目實施SCM紀律，則這個patch會被拒絕掉，然後開發人員需要花費時間重新編寫一個新的patch。重新編寫一個複雜的patch代價是巨大的，而把commit message寫好隻會花費幾分鐘。
盡可能多的送出，單個Commit messages包含的内容不要過多；
标題行以Fix, Add, Change, Delete開始，采用指令式的模式。不要使用Fixed, Added, Changed等等；
始終讓第二行是空白，不寫任何内容；
主體内容注意換行，避免在gitk裡面滾動條水準滑動；
永遠不在 git commit 上增加 -m 或 --message= 參數，送出的時候git commit即可；
如果你是vim使用者，将下面這行代碼加入到~/.vimrc。這會幫助你檢查拼寫和自動換行。
<code>autocmd Filetype gitcommit setlocal spell textwidth=72</code>
Commitizen可以讓你的commit message更加規範統一，适合項目團隊使用，使用也很簡單，使用npm安裝後，送出代碼的時候使用git cz去替代以前的git commit指令即可。
安裝commitizen：
使用截圖：
conventional-changelog是用來從git的中繼資料中生成 Change log文檔的工具，隻要你送出的格式滿足它定義的标準，此處以angular标準為例子。使用它生成的Change log包含以下三個部分：
Bug Fixes Bug修複的資訊
Features 增加的特性
BREAKING CHANGES 重大變更
可以參考它生成的文檔CHANGELOG.md，使用如下：
這不會覆寫你之前的CHANGE.md文檔内容，會在這個檔案的最上面插入新生成的日志資訊。
Git Commit Messages : 50/72 Formatting
Distributed Git - Contributing to a Project
thoughtbot
Erlang otp
Commit messages standard
conventional-changelog-cli
原文連結：http://ivweb.io/topic/58abda9d2117ae2f4995b4a8