在版本控制系统中编写更改消息的准则？

Question

是否有任何关于如何编写changes message版本控制系统的经验法则或指南？

一个明显的答案可能看起来a brief description of the most important changes但实际上，选择最重要的变化并简单地描述这些变化的相关方面并不总是那么容易，特别是在开发的大部分时候，当大块的代码出现时加入。

Answer 1

  

选择最重要的变化并描述这些变化的相关方面并不总是那么容易

如果你保持你的提交紧，并专注于特定的更改，就像“逻辑上单独的变更集”一样：请参阅“git commit frequency”。 （并且不要忘记wrap your comments properly：根据其他处理工具（电子邮件，补丁工具），评论行的长度可能很重要。

Answer 2

这取决于项目的目标。我们使用Git并需要四个字段：

简要摘要（提交的一行主题）

相关故障单（用于与Trac集成）

详细报告

未来的工作要求

我们的Git存储库有钩子，需要正确填写提交消息表单，否则服务器拒绝提交。

通过这种方式，人们可以看到汇总行并了解发生了什么，而详细报告可用于任何棘手的事情，未来的工作可以让每个人都看到仍然存在的问题。

Answer 3

我发现使用过去时动词启动提交消息很有帮助：重构了X类，添加了功能Y ，回滚上一次更改等等。当您稍后再回顾它们时，这种一致的风格使您可以轻松阅读消息日志。

在您的错误跟踪系统中添加对跟踪ID的引用也很有用，因此您可以在必要时调查该更改的完整背景。