變更日誌的意義與重要性​

變更日誌是什麼？​

在軟體專案中，變更日誌（Change Log） 是一份用來記錄專案功能變更、問題修復、優化內容的重要「歷史日記」。這份日誌的對象通常是開發者、測試人員。它可以幫助專案參與者快速掌握專案歷史，甚至在需要版本回滾時節省大量時間。

變更日誌最主要的目的是為了讓大家能「看懂版本變化」。它有幾個很實用的好處：

1. 讓專案更透明，無論是團隊成員還是用戶，都能快速知道每次更新改了些什麼。
2. 提高團隊效率，讓團隊成員快速理解改動，避免重複查詢。
3. 輔助問題追蹤與版本回滾

前言​

在上一篇文章中，我們介紹了如何透過 Commitizen 與 Gitmoji 規範化提交訊息。但規範的建立並不保證會被嚴格執行，許多團隊仍可能面臨這樣的情況：

「提交訊息格式看起來很簡單，但實際操作時，不是漏寫了類型，就是格式寫錯了。」

這種情況下，提交訊息的規範就形同虛設。因此，若要確保提交訊息始終符合規範，勢必得設立一道自動化檢核機制來攔截不合格的提交。

這正是 Commitlint 發揮作用的地方！它專門校驗提交訊息是否符合規範，無論是 Conventional Commits 還是 Gitmoji，都可透過自定義配置嚴格檢查，避免不合格的提交進入版本控制歷史。當然，工具的強大功能需要在正確的時間觸發才能發揮作用，搭配 Husky，我們能利用 Git hooks 在提交前自動執行 Commitlint 的校驗邏輯，將自動化檢核落實於日常開發流程。

本篇文章將帶你實作以下內容：

1. 不使用 Gitmoji 的提交校驗：延續前一篇的配置，透過 @commitlint/config-conventional 校驗提交訊息。
2. 使用 Gitmoji 的提交校驗：加入 commitlint-config-gitmoji 與 commitlint-config-cz，支援帶有 Emoji 的訊息格式。
3. 整合 Husky：將 Commitlint 校驗嵌入 Git Hooks，阻止不符合規範的提交。

前言​

最近我在研究 Git 專案的專業開發流程，比如怎麼按照 Conventional Commits 規範撰寫提交訊息，還有如何根據 Semantic Versioning 原則管理版本號等等。研究過程中，我花了不少時間瀏覽 Github 上一些知名的開源專案，透過它們的提交紀錄、PR 歷史、Change log 和 Release notes，一步步學習怎麼建立一套高效又規範化的工作流程。

經過一段時間的摸索，我慢慢整理出一些具體的流程，未來可以應用在新專案上，比如：

1. 使用互動式問答工具，輔助撰寫符合規範的提交訊息。
2. 配合 Git Hook，自動檢查提交訊息是否遵循規範。
3. 利用規範化的提交紀錄自動生成 Changelog

在實踐這些流程的過程中，我研究了不少相關工具。有趣的是，我發現許多開源專案的提交訊息裡經常出現 Emoji，看起來不僅直觀，還挺有趣的。稍微查了一下後，我才知道這其實是一套叫 Gitmoji 的規範。於是，我決定順便研究一下怎麼把 Gitmoji 整合到剛剛提到的流程中。

由於內容較多，我將以上三個工作階段分成三篇文章來介紹，並在每篇文章中詳細講解有使用 Gitmoji 和未使用 Gitmoji 的情況下，該如何安裝、配置所需工具，以及實際使用的效果。

前言:
最近在公司被分派一個 Koa backend 的功能開發任務，雖然我平時多數時間主要負責前端相關的工作，不過因為學生時期有稍微接觸過一點 Express，它與 Koa 都是 Node.js 知名 web 框架，所以閱讀程式碼時並不會太陌生。這兩者雖然有不少相似之處，但實際使用後發現，它們在設計理念和使用體驗上有很大的不同。