编写git提交消息时要遵循的标准

我发现自己pipe理了很多文件（超过60个，但是低于70个），我的提交消息到目前为止遵循这种模式：当我在layout.css添加类似的东西时，我的提交消息是“在layout.css文件中添加了一些东西”当我删除的东西，我的提交信息是“从layout.css文件中删除的东西” 。

一些文件下来，我看我的提交饲料，并添加…并删除…消息占主导地位。有时我不记得我删除了什么，或者我在layout.css添加了什么，因为我一次做了很多改变，所以我很难提出一个适当的提交消息。

有没有一个标准，我应该遵循，以帮助我拿出我的提交信息？

当你仅仅描述你所做的事情（用技术上的模糊词语，比如“添加了一个函数”），你并没有增加Git已经存储在提交中的东西。想象一下你自己读一些提交信息; 什么样的总结会帮助你最记住/与其他开发者沟通这个变化的本质？确切的内容取决于你的项目和过程，但我觉得这是一个很好的指导方针。

因此，首先添加上下文（ 为什么 ，而不是如何）与您的提交消息（例如“frobnize消息启用持久性”）而不是“添加frob（）函数”）。这是更多的努力（你必须反思和思考），但它是值得更多。

如果你想进一步探索这个话题，那么就有大量的信息，例如Peter Hutterer的博客文章或者这个有趣的幻灯片。

50/72模式似乎是一个很好的做法。即…第一行应该是50个字符长，应服务器作为标题。紧接着一个空格，第二行应该包装成72个字符，并作为总结。这里是一个SO问题： Git Commit Messages：50/72格式化，讨论相同。

这里有关于这个问题的一些详尽的说明：

Git已经知道你在提交中修改了哪些文件，在注释中指定它是没用的。只是说例如“固定填充错误”或“在侧边栏添加菜单”。说清楚，就是这样。