---
# System prepended metadata

title: 'Code Review Guildline: Git Commit Message'

---

# Code Review Guildline: Git Commit Message

## 前言
Commit Message 跟寫程式註解滿像的，最好可以寫下「為什麼」你要做這樣的異動，而不是單單只記錄下你做了「什麼」異動。
> Commit Message 最好兼具 Why & What，讓日後進行維護人員更快進入狀況。


## Commit Message 這樣寫會更好：
- 做 issue 的時候，不應該一次 Commit 所有異動，應該獨立 Commit 每個不同意義的異動，這樣 Commit 訊息才會跟異動的程式有關連。
- 每次 Commit 都是針對異動的檔案做說明：Why & What，這樣的訊息能讓日後新人更快進入狀況。
- 可以的話，每次 Commit 加上 issue 編號，方便追蹤相關程式異動原因 (`issue cas#32`)

## 規範
### Commit Message 規範範例
![example](https://i.imgur.com/ko3rHjm.png)
### Commit Message 範例解析
![example_explain](https://i.imgur.com/jaBgNzl.png)
### Commit Message 規範組成
```
Header: <type>: <subject>
 - type: 代表 commit 的類別：feat, fix, docs, style, refactor, test, chore，必要欄位。
 - subject 代表此 commit 的簡短描述，不要超過 50 個字元，結尾不要加句號，為必要欄位。

Body: 72-character wrapped. This should answer:
 - Body 部份是對本次 Commit 的詳細描述，可以分成多行，每一行不要超過 72 個字元。
 - 說明程式碼變動的項目與原因，還有與先前行為的對比。

Footer: 
 - 填寫專案 issue 編號（如果有的話）
```
#### type 只允許使用以下類別
- **feat**: 新增 or 修改功能 (feature)。
- **fix**: 修補 bug (fix bug)。
- **docs**: 文件，註解 (documentation)。
- **style**: 格式 (不影響程式碼運行的變動 white-space, formatting ...etc)。
- **refactor**: 重構 (既不是新增功能，也不是修補 bug 的程式碼變動)。
- **perf**: 改善效能 (A code change that improves performance)。
- **test**: 增加測試 (when adding missing tests)。
- **chore**: 建構程序或輔助工具的變動 (maintain)。
- **revert**: 撤銷回覆先前的 commit 例如：revert: type(scope): subject (回覆版本：xxxx)。

type 是用來告訴進行 Code Review 的人應該以什麼樣的態度來檢視 Commit 內容。
例如：
- 看到 type 為 fix，進行 Code Review 的人就可以用「觀察改的 Code 如何解決錯誤」，的角度來閱讀程式碼。
- 若是 refactor，則可以專注在程式碼試如何被重構，因為重構的本質是不會影響既有功能。

> 利用不同的 Type 來決定進行 Code Review 檢視的角度，可以提升 Code Review 的速度。

## Commit 訊息範例
### fix
```
fix: 增加 Excluded Referer

把登入網址加入排除的 referer 中，避免無限重新導向。

issue cas#31
```

### feat
```
feat: LoginValidateFormAction 中增加手機驗證的流程

流程包括:
- 使用者確認手機
- 發送手機 OTP 驗證碼
- 使用者輸入驗證碼
- 完成手機驗證

issue cas#32
```

### chore
```
chore: 更新 .gitlab-ci.yml 內依賴的專案

因為 sif 需要新增事件通知的功能，所以增加新增依賴 plus 核心專案

issue sif#87
```

### style
```
style: Format SecurityExpressionUtil

格式重整
```

### refactor
```
refactor: 重構碼頭規則設定更新的邏輯

原本程式散落在多個檔案，
為了讓未來方便維護，統一整理到 DmA100Mod 裡面，

調整項目：
- DmB300Mod 裡的 setDockRule, updateDockSetting 移除
- DmC100Mod 裡的 updateDockUsage 移除

issue sif#78
```

### perf
```
perf: 提升碼頭單據查詢的效能

原本查詢的 api 需要執行大約 5 秒，故做優化。

調整方式：
- 原本：每個碼頭跑迴圈向資料庫取得資料
- 改為：一開始先向資料庫撈取所有資料，再回到 Java 分配資料

結果：查詢時間 5 秒 -> 0.2 秒

issue sif#88
```

### docs
```
docs: 補上 GenerateServiceTicketAction.doPreExecute 方法的註解

issue #32
```