現狀
開發團隊中，總是有人提交代碼時的commit內容亂寫一通，或者不明確不完整。當回溯代碼的時候，很難通過commit內容定位歷史記錄，只能一條一條查看，找不到就要去問歷史參與開發的其他同事，溝通成本太高了。定義commit規范，能夠一定程度解決這個問題，規范一定要簡單，過於嚴苛和復雜會讓提交者厭煩。如果您的團隊采用tapd作為敏捷開發平台，可以參考這套規范。
規范
示例：
TAPD需求標題：類型：主題
解釋：
- 內容由3個部分構成：TAPD需求標題、類型標識和主題，中間用全角或者半角逗號分隔。
- 如果tapd標題很長，可以截取前10到15位，tapd標題必須填寫。
類型列表：
| 類型 | 縮寫 | 解釋 | 必填 |
|---|---|---|---|
| feature | fea | 新功能開發 | 否 |
| fixbug | fix | 修復BUG | 是 |
| test | test | 測試用例 | 是 |
| refactor | ref | 重構，即不是新功能也不是修改bug | 是 |
| build | build | 影響構建或外部依賴項 | 是 |
| style | style | 修改了代碼格式 | 是 |
| doc | doc | 修改了文檔 | 是 |
| other | oth | 其他的修改 | 是 |
示例1：新功能開發
開發需求“訂單滿1000元送優惠券”，commit范例如下：
訂單滿1000元送優惠券：fea：判斷訂單金額 或者 訂單滿1000元送優惠券：判斷訂單金額
由於新功能開發是常態，fea可以省略不寫。如果發現某個地方有優化的空間，但是與本次需求無關，commit范例如下：
訂單滿1000元送優惠券：ref：優化了訂單查詢性能
示例2：解決BUG
需求“訂單滿1000元送優惠券“已上線，后來發現bug，commit范例如下：
訂單滿1000元送優惠券：fix：修復重復贈送優惠券的問題
其他幾種類型，就不一一列舉示例了，這個規范的特點是：通過commit歷史找到對應的tapd，通過tapd的內容回溯業務邏輯。