話說今天本來是打算要接著昨天的進度紀錄架設 grafana 的 dashboard，可是昨天半夜 debug 到一半突然發現，今天不是 PyCon sprints 的日子嗎，剛好我這次打算參與的專案是 commitizen，那我就借題發揮一下，來講講這個題目好了。雖然這跟 SRE 所關注的領域我認為算是稍微有點不同，但是在 DevOps 當中我想也是相當重要的一個部分。

commit message 的重要性

commit message 為什麼很重要？我想下面這張圖應該可以很清楚的說明。記得我在前面幾天的文有寫到，有時候我們難免會將 bug 部屬到生產環境內，在這個時候要讓服務回復運作，比較合理的選項應該是趕緊恢復到上個可以運作的版本，可是若是打開 git history 一看，commit 都長得跟圖片裡面一樣的話，那可就令人頭疼了。BTW，這是真的去 NOJ 的 repo 裡面翻出來的 commit，不過應該都算是蠻久以前的，現在有比較好了。

commitizen 是什麼

那麼這個工具究竟是拿來做什麼的呢？簡單來說它是可以幫助我們寫出良好 commit message 的工具，讓在同一個專案底下工作的每個成員都可以使用一套共同的規範來撰寫漂亮的 commit message，舉例來說，約定式提交 (Conventional Commits) 就是其中一個例子，遵循這套規範的 commit message 看起來大致上會像這樣：

<類型 type>[可選的作用範圍 scope]: <描述 description>

[可選的正文 body]

[可選的頁腳 footer]

可以看到，它是有一個固定格式的，當每個 commit 都按照同樣的規則來撰寫的時候，也就意味著我們可以自動化的從裡面 parse 出各種資訊，進而替專案引入一些方便的功能。

一個比較常見的例子是可以自動更新版號，因為針對每一筆 commit，我們都可以透過 type 欄位，或是檢查 footer 裡面是否有 BREAKING CHANGE 等資訊來判斷一堆 commit 裡面到底產生了多少變更，是修了 bug（對應的 type 是 fix）？還是引入了新的功能（對應的是 feat）？聽說 commitizen 本身已經沒有手動更新版號了，全部都是透過 GitHub Actions 處理。

另一個常見的功能是可以自動產生 changelog，像是下面這張是從 commitizen 的 changelog 截下來的。它就是 parse 兩次版本之間的 commit message，然後再把它傳換成 markdown 格式輸出的結果。當 commit 有共通格式的時候，就可以讓 parse 這件事變得比較簡單，生出來的 changelog 比較好讀。

小結

突然發現，今天好像是我第一次對開源專案發 PR（除了學校的專案，如果那算是開源的話），也是我第一次接觸 commitizen 這個工具，希望以後可以逐漸習慣在專案中使用它。