Scoped Commits
最近在網路上看到了這篇 Stop Using Conventional Commits 文章，談到了 Conventional Commits，我想這個概念大部分有在寫程式的人應該不陌生，甚至只靠 AI 寫程式的人可能也會注意到他們生出來的 commit message 有一定的規範。畢竟這作為一個被廣泛應用的規範已經深植於整個生態系中，也就很大程度上影響了訓練 AI 的資料。
Conventional Commits 的規範如下：
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]最主要的兩者就是 type 跟 description，常被用來做自動化解析 commit message 後生成 changelog 的應用。而我今天看到的 Stop Using Conventional Commits 這篇文章就是在詬病這件事情，作者認為，強調 type 而忽略 scope 是個錯誤的抉擇，因為身為開發者，我們最關心的通常是 scope，也就是這個 commit 與專案的哪個部份有關。而 type 通常可以從 description 那部份辨認出來，並且，很多時候我們難以替 commit 分類，它可能同時屬於 bug 修復或是引入新的 feature。其他還有各種 Conventional Commits 的壞處，可以在文章中看到。
所以他提到了 Scoped Commits，對於 commit message 的格式規範如下：
<scope>: <description>
[optional body]
[optional trailer(s)]變成了 scope + description。事實上，這種規範在不少大型專案中也有採用（應該是在這個 domain 被註冊之前），像是 Linux, Git 或 FreeBSD。而且計中在我入學的時候組內也是採用這樣的規範，不過最近大家可能比較喜歡用 Conventional Commits 吧。整體來說我覺得我比較喜歡 Scoped Commits，但對於專案維護者來說比較需要頭痛的大概是要如何定義 scope，以及當 commit 橫跨多個不同 scope 的時候應該如何撰寫 commit message，因為這好像也不是那麼少見。我在計中內看到的範例是會用 tree-wide 當作全專案 refactor 程度的 scope，但如果是更中間一點的我就不是很確定怎樣比較好，學弟是有跟我講他看過 [scope1], [scope2]: ... 的格式，但我覺得這樣可能也沒很好讀？而且當數量一多的話字數就很限制了。