正确提交消息
什么是提交消息？我一直把它们写成解释我所做的事情，但最近我和一位写同事信息的同事讨论了这个问题，他解释了为什么他这么做。哪一个是对的，还是完全有另一个答案？正确提交消息
注：我完全不知道是否有一个“正确”的答案。因此，我已经将它标记为社区维基，并且不会接受答案。 Upvotes将决定胜利者:)
作为个人偏好，我可以通过直接查看文件中的差异来告诉什么是。 为什么是我不能从推断实际变化中推断出来的。
如果变化很大或很复杂，那么我不仅会包括原因，还会包括如何如何。
我认为两者都有用。有关更改内容的简要说明（“为AddUserForm添加长度验证”）比查看差异更容易，尤其是在浏览多个提交时。为什么改变了，修正了什么错误等等，显然也是一件非常好的事情。
我使用commit消息的的executive summary什么改变。
执行摘要是一个简短的文档，它以这样一种方式进行总结，即读者可以快速熟悉大量材料而无需全部阅读。
的为什么被记录在其他地方：一个问题跟踪系统，需求文档，等等。我还包括从提交信息到为什么链接，反之亦然。
为什么很重要 - 如果你没有在别处记录它，那么把它放在提交消息中。 – 2010-06-10 03:52:31
@theatrus，我绝对同意，但对于任何大中型项目，提交信息不** **的地方来记录你*为什么*。 – Dolph 2010-06-10 03:54:02
@Dolph，我认为提交信息*美好的*的地方，把代码个为什么，但我同意你的看法，这是一个不好的地方，把项目的个为什么。例如：“这段代码因为它在酒吧间隔断而打破了foo”：很好。 “这个功能需要支持来自Foo Inc.的Joe”：糟糕。 – 2012-07-17 02:28:29
提交消息是您对它们所做的，但是当某个文件有数百个或项目数量为几千个时，您希望能够扫描它们以查找某些更改或更改的性质。实际上，它们就像代码注释一样，它们需要尽可能地有帮助，但要简洁明了。也许最好把它们当作tweets--在短暂的空间里传达最大的意义。作为一个跨越几十年的大型代码库，以及跨越一两年的小型项目的工作人员，在梳理提交日志时，我发现没有什么比“oops”或“fixed bug”等消息更让人恼火了。如果你修正了一个错误，告诉我们哪一个错误（一个错误号码，至少）。这对所有不可避免的取证都很重要。
我将提交消息视为电子邮件。 “什么”是主题行，可能引用了一个错误＃，但应该简洁地描述更改 提交消息的主体是原因。 – 2010-06-10 03:53:43
实际上，查看差异告诉你*它是如何完成的，代码中的注释和问题跟踪系统应该告诉你为什么*，并且提交消息应该告诉你*什么*，最好还有一个链接问题跟踪系统。在我看来，当然。 – 2010-06-10 14:43:27
有些更改不容易提交给“评论...应该告诉你为什么”：例如，删除腐烂的代码。每次向注释中添加“为什么”可能会以SCM-in-source-code方案结束。当然，有时候它会添加一条评论来解释为什么在这里添加一些代码的“显而易见的”方法是错误的。 – 2012-07-17 02:24:49