我发现自己管理了很多文件（超过60但低于70），我的提交消息到目前为止遵循这种模式：
当我在layout.css上添加类似内容时，我的提交消息是“在layout.css文件中添加了一些内容”，当我删除某些内容时，我的提交消息是“删除了某些内容来自layout.css文件“。
有些文件在线，我查看我的提交Feed并添加了... 和已删除... 消息占主导地位。有时我不记得我删除了什么或者我在layout.css中添加了什么，因为我一直做了很多改变，所以我很难想出适当的提交消息。
我是否应遵循标准来帮助我提出提交消息？
答案 0 :(得分：75)
当你刚刚描述你所做的事情时（在技术上，模糊的术语，如“添加了一个函数”），你并没有在Git已经存储在提交中的内容中添加太多内容。想象一下自己在一段时间后阅读提交消息;什么样的摘要可以帮助你最记住/与其他开发人员沟通这种变化的本质？！具体内容取决于您的项目和流程，但我发现这是一个很好的准则。
因此，首先要在您的提交消息中添加上下文（为什么，而不是如何）（例如“frobnize the message to enable persistence”）而不是“添加了frob（）函数“）。这是更多的努力（你必须反思并思考），但它更值得。
如果您想详细了解此主题，可以获得大量信息，例如this blog article by Peter Hutterer或this funny slide。
答案 1 :(得分：41)
50/72模型似乎是一种很好的做法。即...第一行应该最多50个字符长，并应作为标题服务器。在一个空格之后，第二组线应该包裹在72个字符处，并且应该作为摘要。这是一个SO问题：Git Commit Messages : 50/72 Formatting，讨论相同的问题。
以下是关于这个主题的一些详尽说明：
答案 2 :(得分：10)
Git已经知道你在提交中修改了哪些文件，在注释中指定它是没用的。只是说例如“固定填充错误”或“在侧边栏中添加菜单”。说清楚，就是这样。