我發現自己管理很多文件（超過60但低於70），並且我的提交消息到目前爲止遵循以下模式： 當我在layout.css上添加類似內容時，我的提交消息是「在layout.css文件」「上添加了一些內容，當我刪除某些內容時，我的提交消息是」從layout.css文件「中刪除了某些內容。編寫git提交消息時遵循的標準
有些文件下了線，我看我提交飼料和加入...和刪除...的消息佔據主導地位。有時候我不記得我刪除了什麼，或者我在layout.css中添加了什麼，因爲我一次做了很多更改，所以我很難提供適當的提交消息。
有沒有我應該遵循的標準來幫助我想出我的提交消息？
當你只是描述你做了什麼（技術又模糊的術語如「添加了一個函數」），你不會增加Git已經存儲在提交中的內容。假設你自己在一段時間後閱讀提交信息;什麼樣的總結會幫助你最記住/向其他開發者傳達這一變化的本質？！確切的內容取決於你的項目和過程，但我覺得這是一個很好的指導方針。
因此，首先添加上下文（爲什麼，而不是如何）與您提交的信息（例如「frobnize消息，使持久性」），而不是「添加FROB（）函數」）。這是更多的努力（你必須反思和認爲），但它更值得。
如果您想要了解有關此主題的更多信息，則有大量信息，例如this blog article by Peter Hutterer或this funny slide。
Git已經知道你在提交中修改了哪些文件，在註釋中指定它是沒用的。只是說例如「固定填充錯誤」或「添加側欄中的菜單」。說清楚，就是這樣。
50/72模型似乎是一個很好的做法。即...第一行應該是50個字符長，並且應該作爲標題的服務器。緊接着一個空格，第二行應該包裝成72個字符，並作爲總結。這是一個SO問題：Git Commit Messages : 50/72 Formatting，討論相同。
以下是關於這個問題的一些詳盡的說明：
http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting – vijay 2013-03-10 17:01:45
這個問題不是一個鏈接的重複。這個問題詢問關於提交消息的內容，而鏈接的問題詢問具體的格式實踐。 – Ajedi32 2014-07-11 18:37:08
黑甘道夫，你去過哪裏？我在這裏，你失去的馬。請不要再離開我！ :-) – 2017-02-07 04:57:14