我发现自己管理很多文件（超过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