點擊藍色「奔跑吧攻城獅」關注我喲git
加個「星標」，每天和你一塊兒奔跑程序員
做爲一名優秀的程序員，做爲一個優秀的團隊，做爲一家優秀的軟件公司，不可能不用版本控制工具。
web
那麼請問，你以爲你填寫 commit 信息以後，過一週、一個月、一季度甚至是一年以後，你還能看得懂當初作過的提交嗎？當一個新同事來修改bug，請教你爲何會這麼修復的時候，你腦海裏是否還能浮現當初深思的場景呢？後端
我在前公司工做那幾年，代碼提交信息都是有嚴格要求，有統一的格式。在提交代碼以前，會經過另外一位同事的協做（即 code review），審查你修復的大體內容，而後填上相應的修改信息才能入庫。微信
這樣的好處是什麼呢？就是能在下一個bug出來以後，很好地往回追溯，以確認是你修改引入，仍是考慮不全，仍是修改無效等。網絡
這樣能更好地提升你寫代碼的能力，當你敲下鍵盤的時候，能考慮更多，能想得更多，更嚴謹。並且，還能在覆盤的時候，有依可循，你以爲呢？app
在那裏3年的時光，讓我養成了提交詳細信息的習慣。因此，當今天看到這篇外文，我饒有興趣地點進去閱讀，想知道歪果仁是如何作好一個優秀的 commit 信息，讀完以後，相信你也能收穫更多。編輯器
先來看看我作的原文翻譯：工具
中止編寫糟糕的提交信息
開始遵循Git提交信息的最佳實踐學習
做者：Devin Soni
時間：1月8日
咱們都見過…
你正在開發一個項目，用到了Git版本控制工具。
你剛完成了一個代碼修改，但願快速地更新到你所在的分支。
這時候，你打開終端，快速敲了幾個命令，就能夠把你更新的信息更新到遠程分支。
用到的命令以下：
gid add
git commit -m "added new feature"
git push
可是，當你作了一些測試，結果發現你的代碼中還存在一個bug。不用擔憂--你很快就解決它，而且又作了一次提交去修復這個bug。
git add
git commit -m "fix bug"
git push
當你重複這個過程好幾回，就會獲得一個提交日誌，以下所示：
此時，這對你來講彷佛挺好的。
畢竟，你持續在作，並且你能夠輕鬆地解釋你在作什麼--即便信息沒有很清楚地傳達。
這個問題
幾個月過去了，如今，另外一個開發人員正在看你所作的更改。
他們試圖去裂解更改的高級細節，可是因爲提交的描述信息有限，他們沒法收集任何信息。
而後，他們去閱讀每一個提交的差別信息。然而，即便這樣作了，他們仍然不能識別出你在實現中當時作的思考過程。
如今，因爲軟件工程是一個協做過程，並且存在git blame操做，因此他們會找出是誰作了修改，並開始向你諮詢關於你的實現問題。
而後，由於時間過去好久，你也記不了多少信息。你經過提交記錄查看，可是也仍是記不得在項目中實現這個修復背後的思想邏輯。
你給你同事發了一個很遺憾的表情，很遺憾的告訴他們，除了他們看到的提交信息，你也不能提供更多有效的信息了。
編寫良好的提交信息
但願上面講的實際狀況，能很好的說明爲何編寫良好的、信息豐富的git提交信息很重要。
在一個像軟件工程同樣須要協做的領域，咱們必須使合做者很容易地在咱們的工做中快速獲取到相應的上下文聯想信息。
在理想狀況下，一個優秀的提交信息應該由三部分組成--主題、正文和結束行。
主題
主題應該單獨成行，寫上你提交記錄的概要信息。
他應該是祈使句，以大寫字母開頭，不用句號結尾，字數不能超過50個字符。（這是英文要求，咱們中文提交能夠作參考，甚至也用英文來寫提交信息）
一個好的主題能夠完成This commit will…這樣的理解（同理，中文就是：這個提交將…：）
一個優秀的提交信息，好比「add new neural netword model to back-end」,(中文：向後端添加新的神經網絡模型)，這樣就很好地完成了這個句子
一個糟糕的提交信息，例如「fix bug」（你中招了嗎？）這個就不能很好的完成句子，從而產生「This commit will fix bug」(這個提交將修復bug)，這樣尷尬的字面理解。
內容
正文包含消息的主要內容，你能夠在其中詳細描述有關更改的信息。也請注意，對弈一些很是小的提交，好比修復一個輸入錯誤，你可能不須要正文，由於主題已經提供了足夠的信息。
在正文中，你應該更詳細地介紹你所作的修改，並解釋你所作修改的上下文內容。
你能夠解釋爲何要進行這些修改，爲何要選擇以這種方式實現這些修改，以及其餘任何能幫助別人理解你思考過程的內容。
儘可能不要重複那些從diff中的代碼修改中能夠很明顯理解的內容，沒有必要逐行解釋你的修改。更多的關注更高層次的細節，這些細節可能在閱讀代碼時並不明顯。咱們的最終目的是爲圍繞這個變動的開發過程提供上下文信息，主要是關注其動機和目標。
結束行
最後，結束行是提交信息的最後一行。
這裏能夠放置關於提交的有用的元數據，好比 JIRA單號、GitHub issue號，做者姓名，以及其餘連接等。這有助於將你修改相關的重要信息連接在一塊兒。（我我的的習慣，加上日期）。
結語
很高興你和我一塊兒學習完了，請問此時的你什麼感想？這裏遇到的問題，你是否曾經遇到過。
若是是，說明你還有很大的提高空間，你修改bug，回溯問題的效率還能更高；若是你已經在作了，那麼恭喜你，請繼續保持。
做爲程序員，基本上天天都在用版本控制工具，編寫良好的 commit 日誌是對本身負責，也是對項目負責，能讓你事半功倍，實踐起來！
做者簡介：躍哥，前菊廠Android攻城獅，現遊戲公司Java主程，奔跑中的技術人！
3、2019元年，110篇原創精華整理，不再用查找歷史記錄啦！
本文分享自微信公衆號 - 程序員小躍（runningdimple）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。