我很好奇应该在版本化文件提交评论中的内容类型。它应该通常描述更改的内容（例如“小部件屏幕被更改为仅显示活动小部件”）或者应该更具体（例如“在fetchWidget查询的where子句中添加了一个新条件，以便仅默认检索活动小部件“）
单个提交的原子性如何？只是在单个提交中包含更新的查询的文件（例如“更新小部件屏幕以默认仅显示活动小部件”），或者应该和屏幕上的其他几个更改+界面更改共享相同的提交以及更一般的描述喜欢（“更新小部件屏幕：A”）默认情况下仅显示活动小部件B）添加按钮以切换显示非活动小部件“）
我看到subversion提交注释的使用方式非常不同，并且想知道其他人的成功与否。有些评论与“更新文件”一样简短，而有些评论的篇幅较长，而其他评论的格式则可以查询并与某些外部系统（如JIRA）相关联。
我曾经非常描述变更的原因以及具体的技术变化。最近我一直在缩减，只是给了一个将军“这就是我在这个页面上改变了”的评论。
答案 0 :(得分：9)
一些指导原则：
答案 1 :(得分：5)
它应简要说明提交包含的内容。这应该包括错误修复或增强的票号。我所听过的关于撰写评论的最好建议是“代码，好像下一个维护你的代码的人是一个知道你住在哪里的杀人疯子”这同样适合提交评论。
答案 2 :(得分：4)
有用的提交注释是那些添加无法从更改本身轻松提取的有用信息的注释。查看差异将显示更改的内容，因此提交注释应集中于解释为何进行更改：
修复因NULL指针取消引用导致的崩溃（错误ID 234）。
添加了与服务器断开连接的命令（功能请求22）。
清理未来更改的代码。
另一种有用的评论是总结一系列更改的总体目的：
答案 3 :(得分：3)
就个人而言，我试着简要总结一下我改变和/或添加的内容。有些东西会让我想起，“哦，是的，这可能是我向业务对象添加额外规则的地方。”因为我总是可以运行“差异”来具体看到改变了什么。
答案 4 :(得分：3)
如果您使用错误跟踪系统，最好包括您正在处理的适用于此更改的错误/增强＃。很多时候，你只会重写那个bug描述中的内容。
答案 5 :(得分：2)
它应包含更改的小摘要（以允许在更改列表中进行过滤）以及更改应用的原因。
新代码的文档属于源代码本身;不在日志消息中。 （并且应删除应用于旧代码的仅的评论。您可以随时通过SCC系统的历史查看这些旧评论。）
答案 6 :(得分：1)
在考虑写什么/不写什么时，有一件事可以帮助我最终应该可以从提交注释中编译内部的技术发行说明。
我还发现在提交注释中建立标记非常有用，例如＃doc，#typo，＃rereoror，......
在提交时我不会过于描述 - 以某种方式做某事的原因应该在文档中，或者在代码注释IMO中。
答案 7 :(得分：0)
使用当前时态，将更改集中为“命令”，将重点放在“为什么”和功能上。
中断行以提高可读性。
使用点分隔相关的更改组。
避免在标点符号后也使用大写字母，以使大写字母仅与代码相关。
当有大量新的顺序“命令”出现时，请避免使用过多的“和”，而应仅使用逗号或;如果您愿意。
创建路线以从登台中获取新帖子，更新数据库，获取RSS feed，添加
PDO缓存功能。在开发环境中删除页脚跟踪脚本。
使用“次要”来描述与“清理代码”或“不有趣的”更改相关的组或单个更改。
未成年人。
或
创建路线以从登台中获取新帖子，更新数据库，获取RSS feed，添加
PDO缓存功能。删除开发中的页脚跟踪脚本
环境。未成年人。
“像没有明天一样”一起提交许多功能时，您总是可以提及特定的行，而我很少使用行信息。
注释错误，第14行。