傳統提交無法拯救你的提交訊息

在網上快速搜尋就會發現大量教你如何撰寫提交訊息的文章，其中 90% 都告訴你要使用 conventional commits。然而，相當多的開發人員仍在這方面苦苦掙扎。他們知道應該遵循這些慣例，但在實踐中卻發現套用它們很困難。每次提交代碼時，他們都會苦惱於到底應寫 "refactor" 還是 "chore"。我甚至見過一些專案，其提交訊息清單完全由同樣的訊息組成："feat: add page"，因為對他們來說撰寫提交訊息太具挑戰性，以至於他們放棄了。

對於傳統提交來說，討論還為時過早#

我不是說傳統提交不好。它們有很多眾所周知的好處：

• 它們提供了一種統一的格式，使提交訊息更加標準化
• 易於自動化工具解析，從而實現自動生成變更記錄
• 幫助團隊成員理解代碼變更的目的和範圍
• 允許快速識別不同類型的代碼變更

然而，當開發人員即使在使用傳統提交後，仍然在撰寫良好的提交訊息上苦惱時，向他們扔一篇關於如何使用傳統提交的文章，教他們什麼是 feat 類型、什麼是 fix 類型，實際上是沒有意義的。這就像給一個不會做飯的人一本高級食譜，而不教他們如何使用基本食材和工具。然而，這樣的文章在互聯網上比比皆是。他們不知道的是，只有當開發人員具有清晰的思維和準確分解任務的能力，傳統提交才能真正發揮作用。

所以，傳統提交並不壞，但在我們談到它之前，我們需要建立正確的開發思維模式，使用科學的開發者思維來做事。

撰寫良好提交訊息的關鍵思維#

代碼變更應該一次做好一件事#

在軟體開發中，「一次做好一件事」是一條重要的原則。這不僅適用於寫代碼，也適用於提交代碼。當我們一次專注於一個特定任務或變更時，我們的代碼變得更加清晰，我們的意圖更加明確。這種方法不僅提高了代碼的可讀性，還大大簡化了代碼審核過程。審核人員可以更容易地理解和驗證每個變更的目的。

此外，這種方法為潛在的代碼回滾提供了便利。如果問題發生，我們可以更容易地定位和還原特定的變更，而不影響其他不相關的部分。最重要的是，當每個變更僅做一件事時，描述此變更的提交訊息自然更加精確和有意義。

實際操作中，這意味著我們需要在開始編碼前明確要完成的任務。一旦完成一個任務，我們應立即提交代碼，而不是等到完成多個任務後再一起提交。如果在完成當前任務時發現其他需要修改的地方，最佳的方法是記下來，待當前任務完成後再分別處理。例如，當你在實現一個功能的同時發現了一些現有的 bug，你不應該立即連同新的功能代碼一起修復 bug，而是應該先實現功能，然後在一個單獨的提交中修復你發現的 bug，或先修復 bug 然後提交功能。

提交訊息其實是在編碼前就存在的#

許多開發人員只有在完成代碼後才開始考慮如何撰寫提交訊息，但實際上，提交訊息應該在我們開始編碼前就存在。這是因為提交訊息本質上反映了我們完成一項任務所採取的步驟。換句話說，它們是我們的待辦事項。

當我們開始一項任務時，我們應首先考慮完成此任務需要哪些具體步驟。這些步驟是我們的待辦清單，同時也是我們未來的提交訊息。擁有了這個待辦清單，我們的每次代碼變更都有了目的，使我們在編碼過程中保持專注，避免偏離任務。

更重要的是，這種方法能顯著提高我們的效率。當我們完成一個步驟時，對應的提交訊息已經準備好，我們可以直接使用它，減少了考慮如何描述變更的時間。同時，因為這些提交訊息是在我們對任務有了全面理解時完成的，它們通常質量更高，信息更豐富。

假設你需要實現一個新的用戶註冊功能。你可以這樣計劃你的任務步驟：

1. 重構現有表單元件以提高泛用性和可重用性
2. 創建用戶註冊表單
3. 實現用戶註冊的 API 集成
4. 為用戶註冊功能添加單元測試
5. 更新用戶註冊功能的文檔

這些任務步驟對應的提交訊息可能如下：

1. refactor: enhance existing form component for reusability
2. feat: create user registration form
3. feat: implement user registration API integration
4. test: add unit tests for user registration
5. docs: update documentation for user registration feature

這樣，在開始編碼前，你就有了明確的任務步驟和對應的簡潔提交訊息。這些提交訊息實際上是你的待辦清單，引導你完成整個功能實現的過程。

當你完成每個步驟時，可以使用對應的提交訊息提交你的代碼。這不僅幫助你更好地組織和執行任務，還確保每次提交都專注於一個特定的步驟，讓整個開發過程更加清晰和可控。如果你在實際編碼過程中需要稍微調整提交訊息，可以進行小修正以更準確地描述實際變更。

傳統提交成為自然而然的選擇#

當我們建立了正確的開發思維，使用傳統提交就變得自然而然。在這個階段，你會發現選擇適當的類型前綴（如 feat、fix、refactor 等）變得毫不費力，因為你的提交訊息已經清晰地反映了你的任務步驟。

如果你想了解更多關於如何使用傳統提交的內容，網上有許多優秀的文章。但記住，這些標準只有建立在正確的開發思維基礎上時，才能真正起到作用。

結論#

撰寫良好的提交訊息不僅僅是遵循某種格式。它要求我們在開發過程中保持清晰的思維，闡明每個變更的目的，並在開始編碼前考慮如何描述我們的工作。

傳統提交確實是一個有用的工具，但只有當它和正確的開發思維結合時，才能發揮最大效果。通過實踐「一次做好一件事」和「提前考慮提交訊息」這兩個原則，我們不僅可以提高提交訊息的品質，還可以提高整體開發效率和代碼質量。

希望這篇文章能幫助你重新思考你的開發過程，並鼓勵你嘗試這些方法。記住，好的開發習慣需要時間去培養，但一旦形成，它們將大大提高你的工作效率和代碼質量。