規範Commit格式
Jenkins根據對比當次構建和上次構建的Commit資訊來生成ChangeLog,但因為我們目前的提交不夠規範,經常有類似"#","update"這列的提交,無法提供給PM有效的更新記錄,所以建議大家儘量規範Commit格式。
Conventional Commits
目前推薦大家是有這套規範,如果大家有更好的可以推薦使用,官網連結如下:
Conventional Commits
官網介紹的很詳細,要求也比較多,有一些我們可能也用不到,而且也會增加學習難度,所以我這邊整理了一下適合我們的規範,比較簡單,但應該夠用,
格式
原文
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
譯文
<型別>[可選 範圍]: <描述>
[可選 正文]
[可選 腳註]
格式說明
示例如下:
type
- fix: 型別 為
fix
的提交表示在程式碼庫中修復了一個bug。 - feat: 型別 為
feat
的提交表示在程式碼庫中新增了一個功能。 - perf:型別 為
perf
的提交表示在程式碼庫中做了效能最佳化。 - style:型別 為
style
的提交表示在不影響程式碼含義的變化(空白,格式化,缺少分號等)。 - docs:型別 為
docs
的提交表示僅更新文件。 - refactor:型別 為
refactor
的提交表示重構,不修復 bug 且不新增功能。
示例屬於新增功能,所以使用了feat
。
optional scope
範圍必須是一個描述某部分程式碼的名詞,並用圓括號包圍。
示例隻影響到BlankSystem,所以scope寫的是這次只針對BlankSystem。
description
描述欄位必須直接跟在<型別>(範圍) 字首的冒號和空格之後。 描述指的是對程式碼變更的簡短總結。
示例總結主要是為了能讓非開發(PM)看懂,方便寫release note,所以儘量用大家都知道的描述。
optional body
在簡短描述之後,可以編寫較長的提交正文,為程式碼變更提供額外的上下文資訊。正文必須起始於描述欄位結束的一個空行後。
示例簡短描述是為了給非開發(PM)檢視,正文是儘量讓研發內部直接看懂,這裡建議大家儘量寫的清楚詳細。
optional footer(s)
如果和每個jira相關,附帶就可以。
CLion示例
1. 下載外掛Conventional Commit
2. Commit
視窗打鉤需要push的檔案,然後郵件選擇Commit Files...
3. Commit
視窗左下角Amend
左鍵紅圈
4. Build Commit Message
填好更新內容,然後會自動更新到Amend