关于评论代码有很多讨论，但评论签到怎么样？版本控制评论的最佳做法
我发现这个博客帖子： http://redbitbluebit.com/subversion-check-in-comment-great-practices/
至于是谁发布说明放在一起的家伙，我正在寻找办法，使这项工作更容易。
目前我们为<Begin_Doc>...<End_Doc>定义了我们自己的方案，用于任何应该发布给我们软件客户的方案。但即使是内部的东西，我也想知道每个变化的“原因”。
每个功能都有一张票/发行/错误报告/任务/无论你打电话给它，并且票号始终在检入注释中引用。这给出了上下文。
我会主张不要使用/重载你的版本控制系统。我建议问题跟踪软件更好。
首先，开发人员在已经存在于需求文档或问题/缺陷系统中的提交消息中添加所有上下文和重复信息似乎不太合适。
您可以使用一个工具来收集提交注释中的相关修复/问题编号，然后从您的其他存储库收集这些修复/问题编号，但我认为基本上使您的修订工具成为面向外部的东西是个错误。
您需要定义Source/version repository/SVN是什么 - 它是用于管理源文件，还是用于编写发行说明。我认为它不应该超载。
关键是你打算怎么处理评论。如果您正在创建发行说明，那么您可以按照您的建议进行操作。不过，我会建议您在其他位置跟踪发行说明，例如在项目管理或错误跟踪工具中。
至于与开发人员相关的评论，我们通常会要求人们解释他们在做什么，一个句子的解释。它不需要太过正式，主要是因为如果是人们会反对它。另外，如果您知道是谁做的，并且您有快速评论，则通常可以追溯该问题并找到该人。
同样，如果您使用的工具如FogBugz，您可以将SVN签入链接到案例编号。这意味着您可以查看案例以获得完整的讨论，评论，截图等。这些信息比您在签入评论中输入的信息多得多。
我会说要尝试遵循changelog风格。第一行应该是一个简短的摘要，并包括问题/票号（如果有的话）。根据VCS处理多行提交消息的方式，这可能会有一个空白行，然后是更完整的多行描述。我认为强加任何严格的格式是不合理的，因为它会阻止频繁的提交，但只要重要提交（那些关闭问题或重大更改）以这种方式完成，就应该没问题。
如果您使用Trac或roundup + svn集成之类的东西，它可以从提交消息中挑选问题编号。因为它们非常有用，我总是会把它们放在第一行。
同意纪念，但你也应该写一点关于你为什么执行修改/错误修复你的方式。 如果您经常在检查中相信，您还应该包括TO DO，以便您的一位同事完成任务。
编辑：鉴于这是我迄今为止最低调的答案，我认为值得强调最后一段隐藏的内容：我是独资经营者。我对这些项目拥有100％的所有权，不与其他开发人员合作。在一家拥有多名开发人员的店铺中，我在这个答案中所说的一切可能完全不合格。
我在这里订阅DRY在所有的东西。
我几乎从不给我的提交添加评论。评论几乎总是重复自己。 “这个提交中改变了什么”这个问题的答案？几乎总是在差异。
当我在查看一个文件并询问“这里发生了什么？”时，我所做的第一件事就是查看以前版本的差异。 90％的答案立刻显现出来，不是因为代码不言而喻，就是因为我在代码中有一些不言自明的东西。如果不是，我将文件的修改日期与错误跟踪系统关联起来，答案就在那里。
这总是有效的。有时需要进行一些调查才能找出问题，因为我没有充分评论我的代码。但我从来都不能很快找到答案。
我唯一一次给提交日志添加注释的时候，我知道差异不会帮助我。例如，当我对一个班级的成员进行排序时：在这种情况下差异会告诉我的唯一事情就是发生了一件非常重要的事情。当我这样做时，我会在修复文件后立即提交该文件。没有适当的地方来评论文件中该范围的更改，因此我添加了一条评论，说明此修订版中的唯一更改是对成员进行重新排序。你可能会问：“为什么你不会在文件顶部修改历史记录中发表类似的修改？”我没有在我的文件顶部保留修订历史记录，这是一个可怕的，打破一生的习惯改变，我从来没有后悔过，修订历史是Subversion。）
如果我没有100％的所有权项目，可能会有所不同。将错误修复与提交相关联可能太难了。培训其他开发人员编写可以有效依赖版本控制的风格可能太难了。我不得不看。
如果在你发布这两年后你的立场发生了改变，我会很好奇。 – 2011-06-23 14:16:45
我推荐功能评论。评论应该提供改变的摘要。如果有什么改变，为什么。每个提交都应该是可以解释的，如果你不能清楚地解释它，你可能不应该检查它。
使用源代码控制日志时要记住的最重要的事情是他们在那里确定何时和什么是改变。功能越多，越详细越好。承诺应在一口大小的片断，这可以解释一口大小的评论。
我个人的偏好是这样的风格：
更新错误日志记录系统。
使我改变小帮助：我可以提供我的变化详细描述这种方式。
的签入注释应该是一个开发者想要的信息：这包括重构，代码背后的动机等
我们尽量保持简单：写一个句子描述了你所提交的变化。如果开发人员需要两个或更多的句子来描述提交，那么提交可能是两个不相关的工作。当这样的提交最终在版本控制中时，很难单独恢复修复。
我们希望在我们的提交评论中包含的另一条信息是提交修复/实现的缺陷/功能号。并非我们所做的所有工作都与我们问题跟踪系统中的缺陷有关，因此这不是强制性的。
我们在我们提交的评论中提供的最后一条信息是名称的一个代码评论者。这是在提交之前对变更进行完整性检查的人员。
在我们的项目中，我们一贯主张提供一些细节什么提交即将在不必重复就像我们使用Trac的，并有我们的资源库整合问题的相关信息，以帮助。其优点是，您可以在评论中引用问题单，并仅说明所执行的解决方案或步骤。然后，Trac自动将参考号码链接到原始问题编号，并将您的提交信息用作问题的评论。然后当你想看看已经做了什么时，你可以简单地阅读Trac中的问题，并有完整的上下文。
至于发布说明我们已经发现，服用一个版本中的问题列表，并使用提交作为意见的基础信息一直很好。通常情况下，您的发行说明中不会包含原始提交消息，因为您的客户并不真正在意每一个细微的变化，甚至可能包含在评论中的详细程度。所以您通常需要进行大量的编辑来突出显示在该版本中实施的主要更改和错误修复。
让您的工作环境，让你可以从售票入住注释直接进入。一种典型的方法是使票号可点击。 – 2011-12-01 09:34:30