什么是提交消息?我一直在写它们来解释我所做的事情,但我最近与一位写提交消息的同事讨论了它,解释了他为什么这样做。哪一个是对的,还是完全有另一个答案?
注意:我完全不知道这是否有“正确”的答案。因此,我已将其标记为社区 wiki,并且不会接受答案。赞成票将决定获胜者:)
什么是提交消息?我一直在写它们来解释我所做的事情,但我最近与一位写提交消息的同事讨论了它,解释了他为什么这样做。哪一个是对的,还是完全有另一个答案?
注意:我完全不知道这是否有“正确”的答案。因此,我已将其标记为社区 wiki,并且不会接受答案。赞成票将决定获胜者:)
作为个人喜好,我可以通过直接查看文件中的差异来判断做了什么。为什么是我无法仅通过查看实际变化来推断的事情。
如果更改很重要或很复杂,那么我不仅会包括原因,还会简要概述如何进行。
我觉得两个都有用。对更改的快速描述(“为 AddUserForm 添加长度验证”)比查看差异更容易,尤其是在您浏览多个提交时。为什么要进行更改,修复了哪些错误等,显然也是一件非常好的事情。
我将提交消息用作更改内容的执行摘要。
执行摘要是一份 [...] 简短的文件,以这样一种方式总结 [...],使读者无需阅读全部内容即可迅速熟悉大量材料。
为什么在其他地方记录:问题跟踪系统、需求文档等。我还包括从提交消息到为什么的链接,反之亦然。
提交消息是您对它们所做的,但是当一个特定文件有数百条消息或一个项目有数千条消息时,您希望能够扫描它们以查找某些更改或更改的性质。实际上,它们就像代码注释,它们需要尽可能有用,但要简洁明了。也许最好将它们视为推文——在短时间内传达最大的意义。
作为一个从事跨越数十年的大型代码库以及跨越一两年的小型项目的人,在梳理提交日志时,我发现没有什么比“oops”或“fixed bug”之类的消息更令人恼火的了。如果您修复了错误,请告诉我们是哪一个(至少是错误编号)。对于未来不可避免的取证来说,这一切都很重要。