基於tapd的git commit規範

現狀

開發團隊中，老是有人提交代碼時的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的內容回溯業務邏輯。