你正在開發乙個專案，它使用 git 進行版本控制。
你剛剛完成更改，並且想要快速更新分支。
因此，你開啟了終端，並通過一些快速命令，使用所做的更改來更新遠端分支。
git add .
git commit -m "added new feature"
git push
不用擔心，你可以快速找到解決方案，並再次提交以解決該問題。
git add .
git commit -m "fix bug"
git push
目前，這對你來說似乎還不錯，畢竟，你目前正在處理該部分**，即使提交的資訊不能傳達你更改的意圖，你仍然可以輕鬆地解釋進行了哪些處理。
幾個月過去了，現在，另乙個開發人員正在回顧你所做的更改。
他們試圖理解你所做更改的細節，但是由於你提交的訊息不是描述性的，因此他們無法獲取任何資訊。
然後，他們嘗試去檢視每個提交的差異。但是，即使這樣做了，他們仍然無法確定你在實現中選擇的背後的思考過程。
因此他們可以使用git blame找出是誰進行了這些更改，並開始向你詢問有關實現的問題。
但是，由於時間已經過去很久了，所以你不會記得太多。你通過提交進行檢查，而你不再記得該專案中執行決策背後的邏輯。
希望以上情況已經讓你明白了為什麼編寫良好的git commit訊息很重要。
在團隊開發中，我們必須使其他協作者能夠輕鬆地理解我們做了什麼工作。
理想情況下，良好的提交訊息將被分為三部分：主題，正文和結尾。
主題應該是簡潔的一行，總結你所提交的更改。
下面例舉乙個很好的提交資訊，例如「feature：查詢專案應用率功能」。
乙個錯誤的提交訊息，例如「fix bug」，在其他人看到這條提交資訊的時候就會不知所措。
正文包含你要傳達的資訊，你可以在其中詳細了解有關更改的資訊。請注意，對於一些很小的提交，例如修正錯字，你可能不需要正文，因為主題行應該足夠有資訊性。
在正文中，你應該深入了解正在進行的更改，並說明正在執行的操作的前因後果。
你可以解釋為什麼要進行這些更改，為什麼要選擇以這種特定方式實施更改以及可以幫助人們理解你的提交背後的思維過程的其他任何原因。
盡量不要重複比較**中顯而易見的事情，無需逐行解釋你的更改，專注於覆蓋更多高階細節，這些細節從閱讀**中可能並不明顯。最終目標是圍繞此更改為開發過程提供上下文，該更改主要涉及其原因和目標。
這有助於將與你的變更相關的重要資訊連線在一起。
還等什麼？等著被同事暴揍嗎？那還不趕緊開始遵循有關 git 提交訊息的最佳實踐！
請停止編寫糟糕的提交訊息！
你正在開發乙個專案，它使用 git 進行版本控制。你剛剛完成更改，並且想要快速更新分支。因此，你開啟了終端，並通過一些快速命令，使用所做的更改來更新遠端分支。git add git commit m added new feature git push 但是隨後你進行了一些測試，發現你的 中存在 b...
jira怎麼提交bug 請停止編寫糟糕的提交訊息
你正在開發乙個專案，它使用 git 進行版本控制。你剛剛完成更改，並且想要快速更新分支。因此，你開啟了終端，並通過一些快速命令，使用所做的更改來更新遠端分支。git add git commit m added new feature git push但是隨後你進行了一些測試，發現你的 中存在 bu...
2018第41週日 請立刻停止做不該做的事
有些知道不該做的事就要立刻停止做。早上聽得到新聞聽到段永平的 停止清單 要明確自己不該做的事清單，並嚴格按照清單執行。就像查理芒格講的 知道自己會死在 的話就絕不去 生活中有很多類似這樣的陷進，有時候我們拖延也是這樣，總給自己找各種藉口去拖延做該做的事或做著自己也知道不該做的事，越陷越深，甚至耽誤終...