基於tapd的git commit規範

現狀

開發團隊中,老是有人提交代碼時的commit內容亂寫一通,或者不明確不完整。當回溯代碼的時候,很難經過commit內容定位歷史記錄,只能一條一條查看,找不到就要去問歷史參與開發的其餘同事,溝通成本過高了。定義commit規範,可以必定程度解決這個問題,規範必定要簡單,過於嚴苛和複雜會讓提交者厭煩。若是您的團隊採用tapd做爲敏捷開發平臺,能夠參考這套規範。
性能

規範

示例:
TAPD需求標題:類型:主題測試

解釋:優化

  1. 內容由3個部分構成:TAPD需求標題、類型標識和主題,中間用全角或者半角逗號分隔。
  2. 若是tapd標題很長,能夠截取前10到15位,tapd標題必須填寫。

類型列表:ui

類型 縮寫 解釋 必填
feature fea 新功能開發
fixbug fix 修復BUG
test test 測試用例
refactor ref 重構,即不是新功能也不是修改bug
build build 影響構建或外部依賴項
style style 修改了代碼格式
doc doc 修改了文檔
other oth 其餘的修改

示例1:新功能開發

開發需求「訂單滿1000元送優惠券」,commit範例以下:code

訂單滿1000元送優惠券:fea:判斷訂單金額 或者 訂單滿1000元送優惠券:判斷訂單金額blog

因爲新功能開發是常態,fea能夠省略不寫。若是發現某個地方有優化的空間,可是與本次需求無關,commit範例以下:
訂單滿1000元送優惠券:ref:優化了訂單查詢性能開發

示例2:解決BUG

需求「訂單滿1000元送優惠券「已上線,後來發現bug,commit範例以下:文檔

訂單滿1000元送優惠券:fix:修復重複贈送優惠券的問題it

其餘幾種類型,就不一一列舉示例了,這個規範的特色是:經過commit歷史找到對應的tapd,經過tapd的內容回溯業務邏輯。table

相關文章
相關標籤/搜索