規範Commit格式

Jenkins根據對比當次構建和上次構建的Commit資訊來生成ChangeLog，但因為我們目前的提交不夠規範，經常有類似"#","update"這列的提交，無法提供給PM有效的更新記錄，所以建議大家儘量規範Commit格式。

Conventional Commits

目前推薦大家是有這套規範，如果大家有更好的可以推薦使用，官網連結如下：
Conventional Commits

官網介紹的很詳細，要求也比較多，有一些我們可能也用不到，而且也會增加學習難度，所以我這邊整理了一下適合我們的規範，比較簡單，但應該夠用，

格式

原文

    <type>[optional scope]: <description>
    
    [optional body]
    
    [optional footer(s)]

譯文

    <型別>[可選 範圍]: <描述>
    
    [可選 正文]
    
    [可選 註腳]

格式說明

範例如下:

type

1. fix: 型別 為 fix 的提交表示在程式碼庫中修復了一個bug。
2. feat: 型別 為 feat 的提交表示在程式碼庫中新增了一個功能。
3. perf：型別 為 perf 的提交表示在程式碼庫中做了效能優化。
4. style：型別 為 style 的提交表示在不影響程式碼含義的變化(空白，格式化，缺少分號等)。
5. docs：型別 為 docs 的提交表示僅更新檔案。
6. 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

5. Amend視窗點選Commit and Push...，然後在Push Commits to xxxx的視窗push

6. 最後在Bitbucket上可以看到提交內容