我发现自己管理着很多文件（超过 60 个但低于 70 个），并且我的提交消息到目前为止都遵循这种模式：当我添加类似 on 的内容时layout.css，我的提交消息是“在 layout.css 文件上添加了一些内容”，当我删除一些东西，我的提交信息是“从 layout.css 文件中删除了一些东西”。
一些文件，我查看我的提交提要并添加......并 删除......消息占主导地位。有时我不记得我删除了什么或添加了什么，layout.css因为我一次做了很多更改，所以我很难想出一个合适的提交信息。
有没有我应该遵循的标准来帮助我提出我的提交信息？
当您只是描述您所做的事情时（用技术但模糊的术语，例如“添加一个功能”），您并没有对 Git 已经存储在提交中的内容添加太多内容。想象一下自己在一段时间后阅读提交消息；什么样的总结最能帮助您记住/与其他开发人员交流该更改的本质？！确切的内容取决于您的项目和流程，但我发现这是一个很好的指导方针。
因此，首先在您的提交消息中添加上下文（为什么，而不是如何）（例如“frobnize 消息以启用持久性”）而不是“添加 frob() 函数”）。这是更多的努力（你必须反思和思考），但它更值得。
如果您想进一步了解这个主题，这里有大量信息，例如Peter Hutterer 的这篇博客文章或这张有趣的幻灯片。
50/72 模型似乎是一个很好的做法。即...第一行的最大长度应为 50 个字符，并且应作为标题服务。后跟一个空格，第二组行应以 72 个字符换行并用作摘要。这是一个 SO 问题：Git Commit Messages : 50/72 Formatting，讨论相同。
以下是有关该主题的一些详尽说明：
Git 已经知道你在一次提交中修改了哪些文件，在注释中指定它是没有用的。只需说例如“修复填充错误”或“在侧边栏中添加菜单”。说清楚，就是这样。