請中止編寫糟糕的提交消息！

我想你們都有過這樣的經歷：

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

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

所以，你打開了終端，並經過一些快速命令，使用所作的更改來更新遠程分支。

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

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

不用擔憂，你能夠快速找到解決方案，並再次提交以解決該問題。

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

你重複此過程幾回，如今最終獲得一個 git commit 日誌，以下所示：

git commit 日誌

目前，這對你來講彷佛還不錯，畢竟，你目前正在處理該部分代碼，即便提交的信息不能傳達你更改的意圖，你仍然能夠輕鬆地解釋進行了哪些處理。

問題

幾個月過去了，如今，另外一個開發人員正在回顧你所作的更改。

他們試圖理解你所作更改的細節，可是因爲你提交的消息不是描述性的，所以他們沒法獲取任何信息。

而後，他們嘗試去查看每一個提交的差別。可是，即便這樣作了，他們仍然沒法肯定你在實現中選擇的背後的思考過程。

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

可是，因爲時間已通過去好久了，因此你不會記得太多。你經過提交進行檢查，而你再也不記得該項目中執行決策背後的邏輯。

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

編寫良好的提交信息

但願以上狀況已經讓你明白了爲何編寫良好的 git commit 消息很重要。

在團隊開發中，咱們必須使其餘協做者可以輕鬆地理解咱們作了什麼工做。

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

主題

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

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

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

正文

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

在正文中，你應該深刻了解正在進行的更改，並說明正在執行的操做的來龍去脈。

你能夠解釋爲何要進行這些更改，爲何要選擇以這種特定方式實施更改以及能夠幫助人們理解你的提交背後的思惟過程的其餘任何緣由。

儘可能不要重複比較代碼中顯而易見的事情，無需逐行解釋你的更改，專一於覆蓋更多高級細節，這些細節從閱讀代碼中可能並不明顯。最終目標是圍繞此更改成開發過程提供上下文，該更改主要涉及其緣由和目標。

結尾

你能夠在最後一行寫有關提交有用的元數據，例如 JIRA 票號，做者名字和附加連接。

這有助於將與你的變動相關的重要信息鏈接在一塊兒。

總結

還等什麼？等着被同事暴揍嗎？那還不趕忙開始遵循有關 Git 提交消息的最佳實踐！

完

●看完這篇還不會用Git，那我就哭了！
●最大的 String 字符長度是多少？
●Nginx 瞭解一下？
●你真的瞭解 volatile 關鍵字嗎？
●Java中Set集合是如何實現添加元素保證不重複的？
●一篇文章帶你瞭解 ZooKeeper 架構

武培軒有幫助？在看，轉發走一波喜歡做者