编写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格式化 ,讨论相同。

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

  1. GIT提供良好的实践
  2. 关于Git提交消息的一个注意事项
  3. 正确的Git提交消息和一个优雅的Git历史

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