重要性超乎想像的提交信息

在開發過程中，我們經常一整天下來都需要撰寫多次提交信息。每次撰寫時，總想對程式碼的變更內容進行良好總結，但由於不易實現，容易寫出模糊不清的信息。

其實，提交信息在當下工作的時候看似並不重要，但當重新檢視等待確認的程式碼或是審查其他成員撰寫的程式碼時，提交信息便成為了重要的提示。

良好的提交信息不僅可提升長期團隊生產力，甚至可在除錯時提供極大幫助。然而，由於提交信息缺乏規約和約束，就如同在沒有命名規範的情況下為變數命名一樣困難。

Conventional Commits

這時發現了Conventional Commits，其規則要求針對程式碼變更選取預先定義的類型，描述範圍及主題，使提交信息更具一致性及標準化，並與Semantic Versioning結合，大大增加生產力。

基本規則如下：

基本規則

1. 格式: type(scope): subject 格式。

   • type: 變更的類型（例如：feat、fix、docs、style、refactor、test等）。
   • scope（選擇性）: 變更的範圍或模組。
   • subject: 簡要説明變更內容。

2. 正文: 若有需要，可進一步説明變更內容。

3. 示例：

feat(auth): 增加用戶登錄功能
fix(api): 修正fetch方法中空指標異常
docs: 更新說明文件中的安裝指引

與Semantic Versioning的約定如下：

若專案遵循Semantic Versioning，提交信息即可自動進行版本控制。例如：

• feat(auth): 增加用戶登錄功能 → 新功能添加 👉 v1.1.0
• fix(api): 修正空指標異常 → 錯誤修復 👉 v1.1.1
• feat(payment): 支持信用卡支付 → 添加新功能 👉 v1.2.0

總結Conventional Commits的優勢如下：

• 保持一致性：一貫的提交信息使得專案歷史顯而易見。
• 自動化工具整合：輕鬆與生成釋出説明、CI/CD流水線等自動化工具整合。
• 高效程式碼審查：迅速了解變更意圖，加快審查進度。
• 增強可擴展性：即使專案增長也能輕鬆維護一致的提交信息。

連加入commitlint也不難(commitlint)

commitlint的主要功能如下：

1. Conventional Commits驗證：確認信息是否符合type(scope): subject格式。
2. 可定製化：根據團隊需求設定規則。
3. CI/CD整合：在流水線中利用commitlint驗證提交信息。
4. 與Husky整合：通過Git hook自動檢測提交信息。

在專案中實施commitlint不僅簡單，且優勢多多，如若團隊採用了Conventional Commits，那也應考慮一起使用commitlint。具體信息可參考commitlint網站。

即便個人能撰寫優質的提交信息，但人往往會因為疏失導致錯誤的增加。相對於向團隊成員反饋不佳信息，抱怨阻擋提交的電腦反而對協作更為高效。

統一提交信息：提升團隊生產力的首要步驟

提交信息不僅是變更記錄，更是協助專案歷史整理與促進團隊協作的重要工具。特別是多位開發人員共同工作時，統一的提交信息使得程式碼審查更高效，對變更的了解也更直觀。

即使在個人層面上，應用固定的規則也能減少不必要的思考，自然就能撰寫出清晰明確的信息，並借助commitlint之類的工具自動驗證信息，防止錯誤發生，且與CI/CD協作無間。

養成適應一定規則撰寫統一信息的小習慣如何？雖初時或許不便，但長久以來勢必對提升團隊生產力大有裨益。