【发布时间】：2011-03-01 23:41:50
【问题描述】：
提交消息有什么用？我一直在写它们来解释我所做的事情，但我最近与一位写提交消息的同事讨论了它，解释了他为什么这样做。哪一个是对的，还是完全有另一个答案？
注意：我完全不知道是否有一个“正确”的答案。因此，我已将其标记为社区 wiki，并且不会接受答案。赞成票将决定获胜者:)
【问题讨论】：
标签： commit version-control commit-message
【发布时间】：2011-03-01 23:41:50
【问题描述】：
作为个人喜好，我可以通过直接查看文件中的差异来判断 什么。 为什么是我无法仅从实际变化中推断出来的。
如果更改很重要或很复杂，那么我将不仅包括原因，还包括如何进行的简要概述。
【讨论】：
-
我将提交消息视为电子邮件。 “什么”是主题行，可能引用了一个错误#，但应该简洁地描述更改提交消息的正文是原因。
-
实际上，查看差异会告诉您如何完成，代码中的 cmets 和问题跟踪系统应该会告诉您为什么，并且提交消息应该告诉你what，最好是附上问题跟踪系统的链接。在我看来，当然。
-
有些更改不容易提交给“cmets ...应该告诉你原因”：例如，删除烂代码。每次将“为什么”添加到 cmets 都可能以 SCM-in-source-code 场景结束。诚然，有时确实添加注释来解释为什么在此处添加一些代码的“明显”方法是错误的。
我认为两者都有用。对更改的快速描述（“为 AddUserForm 添加长度验证”）比查看差异更容易，尤其是在您浏览多个提交时。为什么要进行更改，修复了什么错误等，显然也是一件非常好的事情。
【讨论】：
我将提交消息用作 what 更改的 executive summary。
执行摘要是一个 [...] 简短的文档，它以这样一种方式总结 [...]
why 记录在其他地方：问题跟踪系统、需求文档等。我还包括从提交消息到 why 的链接，反之亦然。
【讨论】：
-
为什么重要——如果你没有在其他地方记录它，那么把它放在提交消息中。
-
@theatrus，我绝对同意，但对于任何中大型项目，提交消息不是记录你的为什么的地方。跨度>
-
@Dolph，我认为提交消息是放置 code-whys 的 好 位置，但我同意你的观点，即放置 project-whys 的位置不好。示例：“此代码破坏了 foo，因为它在 bar 上出现了段错误”：很好。 “需要此功能来支持来自 Foo Inc. 的 Joe”：不好。
提交消息是您对它们所做的，但是当特定文件有数百条消息或一个项目有数千条消息时，您希望能够扫描它们以查找某些更改或更改的性质。实际上，它们就像代码 cmets，它们需要尽可能有用，但要简洁明了。也许最好将它们视为推文 - 在很短的时间内传达最大的意义。
作为一个从事过长达数十年的大型代码库以及一两年的小型项目的人，在梳理提交日志时，我发现没有什么比“糟糕”或“已修复错误”之类的消息更令人恼火的了。如果您修复了错误，请告诉我们是哪一个（至少是错误编号）。这对于未来不可避免的取证非常重要。
【讨论】：