基于tapd的git commit規范

開發團隊中，總是有人提交代碼時的commit內容亂寫一通，或者不明確不完整。當回溯代碼的時候，很難通過commit內容定位歷史記錄，只能一條一條查看，找不到就要去問歷史參與開發的其他同事，溝通成本太高了。定義commit規范，能夠一定程度解決這個問題，規范一定要簡單，過于嚴苛和復雜會讓提交者厭煩。如果您的團隊采用tapd作為敏捷開發平臺，可以參考這套規范。

現狀

開發團隊中，總是有人提交代碼時的commit內容亂寫一通，或者不明確不完整。當回溯代碼的時候，很難通過commit內容定位歷史記錄，只能一條一條查看，找不到就要去問歷史參與開發的其他同事，溝通成本太高了。定義commit規范，能夠一定程度解決這個問題，規范一定要簡單，過于嚴苛和復雜會讓提交者厭煩。如果您的團隊采用tapd作為敏捷開發平臺，可以參考這套規范。

規范

示例：
TAPD需求標題：類型：主題

解釋：

1. 內容由3個部分構成：TAPD需求標題、類型標識和主題，中間用全角或者半角逗號分隔。
2. 如果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的內容回溯業務邏輯。