撰寫 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 工單作為提交訊息，這樣所有內容都可以隨時被連結或追溯，並且代碼庫對未來的開發者保持可維護性。
\ 一些團隊也喜歡在提交訊息中添加表情符號。我已經整理了一份表情符號及其各自含義的列表。你可以在這裡查看。
\ 最終，重要的是你的提交訊息應該有意義，不會讓你的同事開發者或未來的開發者對特定變更的內容感到困惑。
\ 如果你希望了解更多關於約定式提交、語義化提交或行業遵循的實踐，這裡有一些資源供你參考：
- 約定式提交
- 語義化提交
- CBeams 的如何撰寫提交訊息
\
您可能也會喜歡
革命性 CFTC 推動：現貨加密貨幣服務下個月將登陸主要交易所
Nillion – 私人數據的基礎層
