開發團隊中,老是有人提交代碼時的commit內容亂寫一通,或者不明確不完整。當回溯代碼的時候,很難經過commit內容定位歷史記錄,只能一條一條查看,找不到就要去問歷史參與開發的其餘同事,溝通成本過高了。定義commit規範,可以必定程度解決這個問題,規範必定要簡單,過於嚴苛和複雜會讓提交者厭煩。若是您的團隊採用tapd做爲敏捷開發平臺,能夠參考這套規範。
性能
示例:
TAPD需求標題:類型:主題測試
解釋:優化
類型列表:ui
類型 | 縮寫 | 解釋 | 必填 |
---|---|---|---|
feature | fea | 新功能開發 | 否 |
fixbug | fix | 修復BUG | 是 |
test | test | 測試用例 | 是 |
refactor | ref | 重構,即不是新功能也不是修改bug | 是 |
build | build | 影響構建或外部依賴項 | 是 |
style | style | 修改了代碼格式 | 是 |
doc | doc | 修改了文檔 | 是 |
other | oth | 其餘的修改 | 是 |
開發需求「訂單滿1000元送優惠券」,commit範例以下:code
訂單滿1000元送優惠券:fea:判斷訂單金額
或者 訂單滿1000元送優惠券:判斷訂單金額
blog
因爲新功能開發是常態,fea能夠省略不寫。若是發現某個地方有優化的空間,可是與本次需求無關,commit範例以下:
訂單滿1000元送優惠券:ref:優化了訂單查詢性能
開發
需求「訂單滿1000元送優惠券「已上線,後來發現bug,commit範例以下:文檔
訂單滿1000元送優惠券:fix:修復重複贈送優惠券的問題
it
其餘幾種類型,就不一一列舉示例了,這個規範的特色是:經過commit歷史找到對應的tapd,經過tapd的內容回溯業務邏輯。table