git commit是將變更提交到本地緩存中而存在的，同時在commit時需要附上描述信息，說明本次提交是做了哪些變更，以便在今后追蹤代碼時，通過描述信息就能讓讀者知道哪些地方變化了。

這是一把雙刃劍。用好了，能夠保持項目提交記錄清晰，起到追蹤信息的作用；反之，則會帶來更多的困擾。

下面我們就來看看應該如何用好git commit。

好的Commit的特點

提交的變更要單一且聚焦

一次好的commit應該是原子性的 - 即有且僅有一個邏輯的改變。請不要把多個相互獨立的變更一次性提交。

例如：好的提交：只增加了用戶驗證就是一個單一的功能改變。

git commit -m "Add user authentication"

不好的提交：既增加了用戶驗證，同時又更新了UI樣式

git commit -m "Add user authentication and update UI styles"

明確的描述信息

一個具體的描述能夠清晰的解釋該次commit做了什么，并且做了什么改動。在用戶不用閱讀代碼的情況下，就能清晰的知道本次提交做了哪些改變。

好的提交：在用戶登錄功能中，修復了空指針導致的異常

git commit -m "Fix Correct null pointer exception in user login"

壞的提交：修復了一個bug。

git commit -m "Fix bug"

遵循統一的提交風格

遵守統一的提交風格，以保證在讀commit的時候格式統一、一致，以提高易讀性。一般遵循如下格式：

提交的類型+簡短的描述

提交的類型一般包括：

• feat：新功能
• fix：修復bug
• chore：雜項
• refactor：代碼重構
• style：代碼風格變動
• test：測試代碼變動
• build：構建代碼變動

例如：在auth模塊中增加了基于JWT的驗證的新功能。

git commit -m "feat(auth): add JWT-based authentication"

在login模塊中，修復了競態條件的問題。

git commit -m "fix(login)：resolve race condition in login flow"

上面括號中的auth和login說明本次提交所作用的功能范圍。

經過測試和驗證的代碼

確保提交的代碼是經過測試和驗證過的代碼。提交未測試的代碼會影響整個代碼流程以及其他團隊成員。

不好的Commit的特點

一次提交有大量變更且不聚焦

一次提交包含大量的修改是不好的commit。這會導致難以理解本次commit到底修改了什么。一次提交過多的修改，會對代碼review和調試造成困難。

例如：以下是對整個項目做了修改并一起提交了

git commit -m "Update project"

提交的描述模糊不清

提交的描述說明模糊或對本次更改描述不清。這種描述信息缺乏細節且容易造成混亂，同時，也使追蹤歷史變化變的更困難。

例如：以下沒有說明具體的變更是什么。

git commit -m "Stuff"

一次提交中有不相關的變更

將無關的更改合并到一個提交中，難以區分特定的更改，還會引入錯誤并使review過程變的復雜。

例如：以下把readme的修改和login模塊的修改混合在了一起

git commit -m "Update readme and fix login issue"

不完整或沒有經過測試的代碼

提交不完整或未經測試的代碼可能會讓工作流程混亂，給其他團隊成員帶來困擾。

缺少上下文

在提交的說明中，缺少必要的上下文信息，難以理解為什么要做出這次變更。

總結

良好的commit對于在Git中保持干凈和可理解的項目記錄非常重要。通過遵循最佳實踐，如保持提交的單一性、編寫描述性消息、確保是經過測試的代碼等，好的commit可以改善團隊協作，使項目具有高度的可維護性。

原文地址：https://dev.to/sheraz4194/good-commit-vs-bad-commit-best-practices-for-git-1plc?ref=dailydev