撰寫 Git Commit 訊息的最佳方式：就像專業人士一樣

當開發人員回溯時間查找六個月前曾經處理過的內容時，很多時候他不理解為什麼做了特定的提交，而唯一的原因是因為他沒有遵循正確的提交訊息撰寫方式。

\ 全球開發者都在實踐提交訊息標準，遵循流行標準是很好的做法，這樣當你在相當長的時間後回來查看，或者其他人查看你的提交訊息時，它們不會顯得令人尷尬！

\

\ 團隊應該首先決定一個提交訊息約定，用於指定他們正在構建的產品的版本控制歷史。

\ 一個優秀的 Git 提交訊息應該具有適當的風格、內容和元數據。

\ 一個知名的 Git 提交遵循這種約定：

<type>(<scope>): <message>

\ <type> 可以是以下之一：

• feat 用於新功能。
• refactor 用於重構生產代碼，例如，重命名函數。
• docs 用於文檔變更。
• fix 用於修復用戶的錯誤。
• perf 用於性能改進。
• style 用於格式變更，缺少分號等。
• test 用於添加缺失的測試，重構測試。
• build 用於更新構建配置、開發工具或其他與用戶無關的變更。

\ 你也可以根據你團隊遵循的標準添加自定義類型。上述標準是由 ESLint 團隊遵循的。你可以在這裡查看他們的提交訊息。

\ 範圍是可選的，而訊息部分應包含一個單行陳述，不超過72個字符，總結提交的目的。

\ 許多開發者也將訊息作為主題行並添加正文；這基本上是提交的描述，但只要你能理解上下文（提交的內容和原因），單行提交訊息是更可取的。如果提交需要更詳細的描述，而無法在單行中解釋，提交正文始終是必要的。

\ 你也可以使用像 Glitter 或 Commitizen 這樣的工具來標準化你的提交訊息。

\ 不僅如此，你可能還想知道是否有工具可以檢查你的提交訊息，並在不符合指南時彈出錯誤。Commit lint 就是其中之一。它幫助你的團隊遵守提交約定。

\ 很多時候，行業專家使用他們的 JIRA 或 Click Up 工單作為提交訊息，這樣所有內容都可以隨時被連結或追溯，並且代碼庫對未來的開發者保持可維護性。

\ 一些團隊也喜歡在提交訊息中添加表情符號。我已經整理了一份表情符號及其各自含義的列表。你可以在這裡查看。

\ 最終，重要的是你的提交訊息應該有意義，不會讓你的同事開發者或未來的開發者對特定變更的內容感到困惑。

\ 如果你希望了解更多關於約定式提交、語義化提交或行業遵循的實踐，這裡有一些資源供你參考：

1. 約定式提交
2. 語義化提交
3. CBeams 的如何撰寫提交訊息

\