規範提交不會拯救你的提交訊息
探討為什麼僅僅遵循規範提交並不足以撰寫好的提交訊息，並介紹改善開發流程和自然創造有意義提交的關鍵思維策略。
Developer
在互聯網上快速搜索一下，就會找到大量教你如何撰寫提交訊息的文章。這些文章中有 90% 告訴你使用規範提交。然而，仍有相當多的開發者在這方面掙扎。他們知道他們應該遵循這些規範，但卻發現很難在實踐中應用它們。每當他們提交代碼時，他們就會為寫"重構"還是"日常"而苦惱。我甚至見過一些專案的提交訊息列表完全由相同的訊息組成："feat: 新增頁面"，因為撰寫提交訊息對他們來說太具挑戰性，他們乾脆放棄了。
現在談規範提交還為時過早
我不是說規範提交不好。它們有許多眾所周知的好處：
- 它們提供了一個統一的格式，使提交訊息更加標準化
- 它們容易被自動化工具解析，從而實現自動生成變更日誌
- 它們幫助團隊成員理解代碼變更的目的和範圍
- 它們允許快速識別不同類型的代碼變更
然而，當一個開發者即使使用了規範提交後仍然掙扎於撰寫好的提交訊息時，給他們傳授如何使用規範提交的文章，教他們feat類型是什麼意思，fix類型是什麼意思，其實並沒有意義。這就像給一個不會做飯的人一本高級食譜，卻沒有教他們如何使用基本的食材和器具。然而，這樣的文章在互聯網上比比皆是。很少有人知道，只有當開發者具備清晰的思維以及精確劃分任務的能力時，規範提交才能真正發揮作用。
所以，規範提交並不是壞事，但在我們談到這個之前，我們需要建立正確的開發心態，並使用具科學性的開發者思維去做事情。
撰寫良好提交訊息的關鍵思維
代碼變更應一次只做一件事
在軟件開發中，"一次只做一件事"是一項重要原則。這不僅適用於寫代碼，也適用於提交代碼。當我們專注於一次只做一個特定任務或變更時，我們的代碼變得更清晰，我們的意圖更加明確。這種方法不僅改善了代碼的可讀性，還大大簡化了代碼審核過程。審核者可以更容易地理解和驗證每個變更的目的。
此外，此方法為潛在的代碼回滾提供了便利。如果出現問題，我們可以更輕鬆地定位並回退具體變更，而不影響其他無關部分。最重要的是，當每個變更只做一件事時，描述此變更的提交訊息自然變得更準確、更有意義。
在實踐中，這意味著在開始編碼之前，我們需要明確界定要完成的任務。在完成一個任務後，我們應立即提交代碼，而不是等到完成多個任務後再一起提交。如果在完成當前任務時發現其他需要修改的地方，最好的方法是將這些地方記下來，並在完成當前任務後單獨處理。例如，當你在實現某個功能時，發現一些現有的漏洞，你應該做的不是立即修復這些漏洞並與新功能代碼一起提交，而是先實現該功能，然後在另一個提交中修復發現的漏洞，或者先修復漏洞再提交功能。
提交訊息應在編碼前就存在
許多開發者只是在完成代碼後才開始考慮如何撰寫提交訊息，但實際上，提交訊息應在我們開始編碼前就存在。這是因為提交訊息本質上反映了我們完成任務的步驟。換句話說，它們是我們的待辦事項。
當我們開始一項任務時，我們應首先考慮完成此任務需要哪些具體步驟。這些步驟就是我們的待辦事項，同時，它們也是我們未來的提交訊息。擁有這個待辦清單，我們的每次代碼變更都有其目的，使我們在編碼時保持專注，避免偏離任務。
更重要的是，此方法可以顯著提高我們的效率。當我們完成一個步驟時，對應的提交訊息已經準備好了，我們可以直接使用它，減少思考如何描述變更的時間。與此同時，由於這些提交訊息是在我們對任務有全面理解時完成的，它們通常質量更高且信息更豐富。
假設你需要實現一個新的用戶註冊功能。你可能會這樣規劃你的任務步驟：
- 重構現有的表單組件使其更加通用和可重用
- 創建用戶註冊表單
- 實現用戶註冊的 API 集成
- 為用戶註冊功能添加單元測試
- 更新用戶註冊功能的文檔
與這些任務步驟相對應的提交訊息可能如下：
refactor: 加強現有表單組件的可重用性feat: 創建用戶註冊表單feat: 實現用戶註冊 API 集成test: 添加用戶註冊的單元測試docs: 更新用戶註冊功能的文檔
以這樣的方式，你在開始編碼之前就擁有明確的任務步驟和相應的簡潔提交訊息。這些提交訊息實際上就是你的待辦清單，引導你完成整個功能實現的過程。
隨著你完成每一個步 驟，你可以使用相應的提交訊息提交你的代碼。這不僅有助於你更好地組織和執行任務，還確保每個提交專注於一個特定步驟，使整個開發過程更清晰且更易於管理。如果在實際編碼過程中需要稍微調整提交訊息，你可以對其進行微小修改，以更準確地描述實際變更。
規範提交成為自然選擇
當我們培養了正確的開發心態後，使用規範提交便變得順其自然。在這個階段，你會發現選擇合適的類型前綴（如 feat、fix、refactor 等）變得毫不費力，因為你的提交訊息已經清晰地反映了你的任務步驟。
如果你想了解更多關於如何使用規範提交的資訊，網上有很多優秀的文章。但要記住，這些標準只有在基於正確開發心態的基礎上才能真正生效。
結論
撰寫好的提交訊息不僅僅是遵循某一格式。這需要我們在開發過程中保持清晰的思維，明確每次變更的目的，並在我們開始編碼前考慮如何描述我們的工作。
規範提交確實是一個有用的工具，但只有當其與正確的開發心態相結合時才能發揮最大效果。通過實踐"一次只做一件事"和"提前考慮提交訊息"這兩個原則，我們不僅可以提高提交訊息的質量，還可增強整體開發效率和代碼質量。
希望本文能幫助你重新思考你的開發過程，並鼓勵你嘗試這些方法。記得，良好的開發習慣需要時間去培養，但一旦形成，它們將極 大地提高你的工作效率和代碼質量。