Git commit message 的寫法 - oracle-design/guides GitHub Wiki

事實上 git commit 的寫法並沒有一個硬性的規範，但如果能夠有個統一規範的話，在翻閱歷史紀錄時（尤其是多人協作的情形下）將會更容易閱讀。

大原則

基本上依照以下的格式來書寫 commit。

• 第一行
  • 這次變更的內容「概要」（標題）。
• 第二行
  • 留空
• 第三行
  • 這次變更的詳細內容與理由等。

第一行

依照 commit 的類別，在這行的開頭做出適當的標記。大概的格式會像下面這樣： [commit 類別] commit message.

commit 類別

大致上可以分類為以下幾種：

• fix：bug 修正
• hotfix：緊急嚴重的 bug 修正
• add：新增檔案或功能
• modify：功能上的修正（非 bug）
• change：功能或規格變更
• clean：程式碼整理（refactor）
• disable：拿掉某功能（comment out）
• remove：刪除檔案
• upgrade：版本更新
• revert：取消變更

概要

簡單描述這次 commit 的內容、達成的目的。

例如：[fix] 文字輸入框無法辨識 （可以的話盡量用英文來書寫，例如 [fix] text area unreadable issue.

第三行

在這個部分可以具體的寫下 commit 的內容與程式修改的理由。給 redmine 之類的 issue tracking 系統自動辨識的 trigger 也可以寫在這個部分。

例如：done #201 將文字輸入框的背景色加深 20% 提高對比。

完整的 commit 寫法

綜合上面的敘述，完整的寫法會像下面這樣。

[fix] 文字輸入框無法辨識

done #201 將文字輸入框的背景色加深 20% 提高對比。

關於 commit 的分割單位

究竟什麼時候該 commit，分割的細度應該切割到什麼程度，這其實也沒有一個標準。但可以明確的說，修正了一堆 bug 或寫完了好幾個功能才 commit 是個不太好的習慣。

基本上，「完成一件事情」之後就應該 commit，由自己決定什麼程度稱之為完成一件事情，並有一致的標準可以遵循就可以了。

---

附註

關於 redmine 的 trigger，目前我們使用的有以下幾個：

• refs, references, IssueID
  這三個可以把 commit 與 ticket 做關聯，例如 commit message 中如果有 refs #58 ，就會自動和該張票建立關聯。

• fixed, done
  這兩個除了將 commit 與 ticket 建立關聯之外，還會順便把 Ticket 狀態變更為「已解決」，完成百分比設定為「100%」。例如 done #38

• doing 這個可以把 Ticket 的狀態變更為「實作中」。例如 doing #88

另外，也可以順便把花費時間寫到 commit message 讓 redmine 自動幫你記錄時間。只要在 trigger 和票號後加上 @時間 就可以了。例如：

fixed #18 @0:47

关于你文中提到的redmine和trigger，我现在也准备做redmine和gerrit的关联，你能把你的脚本贴下么，想做个参考.谢谢!