mar*_*rkn 20 version-control comments
有很多关于评论代码的讨论,但是如何评论签到？
我找到了这篇博文:http: //redbitbluebit.com/subversion-check-in-comment-great-practices/
作为正在整理发行说明的人,我正在寻找方法使这项工作更容易.
目前,我们<Begin_Doc>...<End_Doc>为应该发布给我们软件客户的任何内容定义了我们自己的方案.但即使对于内部的东西,我也想知道每个变化的"原因".
我建议不要使用/重载你的版本控制系统.我建议问题跟踪软件更合适.
首先,让开发人员在需求文档或问题/缺陷系统中的提交消息中添加所有上下文和重复信息似乎不合适.
您可以使用工具收集提交注释中的相关修订/问题编号,然后从其他存储库中收集这些数据,但我认为基本上使您的修订工具成为面向外部的工具是错误的.
您需要定义源/版本存储库/ SVN是什么 - 它是用于管理源文件,还是用于编写发行说明.我认为它不应该超载.
我们尽量保持简单：写一句话描述您正在提交的更改。如果开发人员需要两个或更多的句子来描述提交，那么提交可能是两个不相关的工作。当像这样的提交最终进入版本控制时，就很难单独恢复修复。
我们希望在提交注释中包含的另一条信息是提交修复/实现的缺陷/功能编号。并非我们所做的所有工作都与我们的问题跟踪系统中的缺陷有关，因此这不是强制性的。
我们放在提交注释中的最后一条信息是一位代码审查者的姓名。这是在提交发生之前对更改进行完整性检查的人。
| 归档时间： |
|
| 查看次数： |
4332 次 |
| 最近记录： |