我想大家都有過這樣的經歷：

你正在開發一個項目，它使用 Git 進行版本控制。

你剛剛完成更改，并且想要快速更新分支。

因此，你打開了終端，并通過一些快速命令，使用所做的更改來更新遠程分支。

git add .
git commit -m "added new feature"
git push 

但是隨后你進行了一些測試，發現你的代碼中存在 bug。

不用擔心，你可以快速找到解決方案，并再次提交以解決該問題。

git add .
git commit -m "fix bug"
git push 

你重復此過程幾次，現在最終得到一個 git commit 日志，如下所示：

    

目前，這對你來說似乎還不錯，畢竟，你目前正在處理該部分代碼，即使提交的信息不能傳達你更改的意圖，你仍然可以輕松地解釋進行了哪些處理。 

問題

幾個月過去了，現在，另一個開發人員正在回顧你所做的更改。

他們試圖理解你所做更改的細節，但是由于你提交的消息不是描述性的，因此他們無法獲取任何信息。

然后，他們嘗試去查看每個提交的差異。但是，即使這樣做了，他們仍然無法確定你在實現中選擇的背后的思考過程。

因此他們可以使用 git blame 找出是誰進行了這些更改，并開始向你詢問有關實現的問題。

但是，由于時間已經過去很久了，所以你不會記得太多。你通過提交進行檢查，而你不再記得該項目中執行決策背后的邏輯。

最終，你在微信上向同事發送了悲傷的表情符號 ????，并告訴他們你不能提供除他們知道以外的更多信息。 

編寫良好的提交信息

希望以上情況已經讓你明白了為什么編寫良好的 git commit 消息很重要。

在團隊開發中，我們必須使其他協作者能夠輕松地理解我們做了什么工作。

理想情況下，良好的提交消息將被分為三部分：主題，正文和結尾。

主題

主題應該是簡潔的一行，總結你所提交的更改。

下面例舉一個很好的提交信息，例如“feature：查詢項目應用率功能”。

一個錯誤的提交消息，例如“fix bug”，在其他人看到這條提交信息的時候就會不知所措。

正文

正文包含你要傳達的信息，你可以在其中詳細了解有關更改的信息。請注意，對于一些很小的提交，例如修正錯字，你可能不需要正文，因為主題行應該足夠有信息性。

在正文中，你應該深入了解正在進行的更改，并說明正在執行的操作的前因后果。

你可以解釋為什么要進行這些更改，為什么要選擇以這種特定方式實施更改以及可以幫助人們理解你的提交背后的思維過程的其他任何原因。

盡量不要重復比較代碼中顯而易見的事情，無需逐行解釋你的更改，專注于覆蓋更多高級細節，這些細節從閱讀代碼中可能并不明顯。最終目標是圍繞此更改為開發過程提供上下文，該更改主要涉及其原因和目標。