代码提交评论的最佳实践

Question

您对代码提交的评论使用了什么模板？

模板的一个示例是:

1. (更改1):(源文件1.1,1.2):(更改的详细信息),(为什么)
2. (更改2):(源文件2.1):(更改的详细信息),(为什么)

理想情况下,每个更改都应映射到问题跟踪器中的问题.这个模板好吗？

Answer 1

以下是我的想法...根据您的特定开发方法,所有这些都可以解释.

• 您应该经常提交,每次提交只需一个焦点,因此基于此,注释应该简短并详细说明提交的重点.
• 我很喜欢在你的评论中发布什么,以及为什么以及如何在其他地方详细说明(最好是在你的错误跟踪中).为什么应该是机票,在关闭机票时,你应该有一些关于如何解决这个特定问题的说明.
• 如果不以其他方式处理(例如TRAC/SVN交互),则对您的错误跟踪系统的引用是好的.这样做的原因是,如果他们正在寻找有关提交的更多信息,则指向其他开发人员正确的方向.
• 除非需要修复非常复杂和详细,否则不要包含特定的文件名.即便如此,复杂的细节可能属于使用您的实施说明进行错误跟踪,而不是版本控制.编辑的文件,差异细节等应该包含在版本控制中,我们不想花时间复制它.

鉴于这些想法,我的一个示例提交评论将是类似的

Req3845:更新了验证,以使用Req3831中开发的新RegEx验证.

简而言之,传达改变的内容,并为其他人提供某种参考,以获得更多信息而不会让你失望.

Answer 2

我在每个段落前加上+ - *或!

+ means its a new feature
- means feature is removed
* means feature is changed
! means bugfix

我不认为你应该提交有关代码的哪些部分被更改的详细描述,因为这就是每个VC都有差异的原因:)