正确的提交消息
提交消息有什么用？我一直在写它们来解释我所做的事情，但最近我与一位同事进行了讨论，他写了提交消息来解释他这样做的原因。哪一个是正确的，或者完全有另一个答案？
注意：我完全不知道是否有“正确”的答案。因此，我已将其标记为社区维基，并且不会接受答案。投票决定获胜者:)
What are commit messages for? I've always been writing them as an explanation of what I did, but I've recently gotten into a discussion about it with a colleague who writes commit messages explaining why he did. Which one is right, or is there another answer entirely?
NOTE: I have absolutely no idea if there is a "right" answer for this. As such, I've labeled it community wiki and will not accept an answer. Upvotes shall decide the winner :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
根据个人喜好，我可以通过直接查看文件中的差异来判断做了什么。 原因是我无法仅从实际变化中推断出来的。
如果更改重大或复杂，那么我不仅会说明原因，还会简要概述如何。
As a personal preference, I can tell what was done by looking at the differences in the files directly. The why is the thing I can't infer from just looking at the actual changes.
If the changes are significant or complicated, then I would include not only the why, but also a brief overview of the how.
我认为两者都有用。快速描述更改内容（“为 AddUserForm 添加长度验证”）比查看差异更容易，尤其是在浏览多个提交时。为什么要进行更改、修复了哪些错误等等，这显然也是一件非常好的事情。
I think both are useful. A quick description of what changed ("Adding length validation for AddUserForm") is easier than looking at a diff, especially if you're browsing multiple commits. Why the change was made, what bug it fixed, etc. is obviously a very good thing to have, too.
提交消息是您所制作的，但是当某个特定文件有数百条提交消息或一个项目有数千条提交消息时，您希望能够扫描它们以查找某些更改或更改的性质。实际上，它们就像代码注释，需要尽可能有帮助，但又简洁明了。也许最好将它们视为推文 - 在短时间内传达最大的含义。
作为一个工作过数十年的大型代码库以及跨度一两年的小型项目的人，在梳理提交日志时，我发现没有什么比“oops”或“fixed bug”这样的消息更令人恼火的了。如果您修复了错误，请告诉我们是哪个错误（至少是错误编号）。这对于今后不可避免的取证工作非常重要。
Commit messages are what you make of them, but when there are hundreds of them for a particular file, or thousands for a project, you want to be able to scan through them looking for certain changes or the nature of the changes. In effect, they are like code comments, and they need to be as helpful as possible, yet concise and pithy. Maybe best to think of them as tweets - convey maximum meaning in a short space.
As somebody who's worked on large code bases spanning decades, and also smaller projects spanning a year or two, I've found nothing more infuriating when combing commit logs than messages like "oops" or "fixed bug". If you fixed a bug, tell us which one (a bug number, at the very least). It's all important for the inevitable forensics down the road.
我使用提交消息作为 的执行摘要改变了什么。
原因记录在其他地方：问题跟踪系统、需求文档等。我还包含从提交消息到原因的链接，反之亦然。
I use the commit message as an executive summary of what was changed.
The why is documented somewhere else: an issue tracking system, requirements documentation, etc. I also include links from the commit message to the why, and vice versa.