团队出现这样的场景大家一般怎么处理

我们是以任务为单位commit（也不排除一个任务会commit多次，毕竟难免有修改）。
频繁的commit，那提交代码时的注释就难写了，哈哈，我们每次提交代码都要写上详细的说明。
从维护代码的角度来说，如果查看代码修改记录，我希望看到的是“某某功能已实现……”“某bug已修复”，而不是“单元测试testFun1已通过”，“单元测试testFun2已通过”

新加入模块或功能在完成工作当前构建工程，存在问题大家协助解决，楼主的问题表面看是个人问题，实际上是团队协助的协议问题，就像没有确定是使Http或socket的通讯协议最后出现了通讯问题一样。

看来你们的工具集成度还不高，我们是通常使用mylyn来集成issue trace，SCM和eclipse，其中注释部分，在你激活一个任务时，会自动填写。
以任务为单独的话，提交的频率就有点低了，往往无法达到很短周期的错误反馈。

对了，大家在svn提交代码时，对注释的写法有规定相关的模板不？不同程序员，提交同一功能，写注释的方式有可能差异很大，如何控制？

关于提交代码的注释，我觉得mylyn所提供的方式挺好。自己使用了一段时间感觉不错，现在打算在团队中推行。
个人觉得他的优点在于：
1、假设你是定的当前Task，他会以Task为核心给你组织你使用到的代码。当你提交这些代码的时候就会加上相应的Task相关的内容。以后查看代码的人或自己对重新查看这个部分代码的时候不光可以了解当前修改的细节还可以了解这些代码的整体目标。
2、他的代码注释会自动帮你加上一部分公用的，比如：相关Task的Title、以及对应的url。这样以来可以提到一个提醒的作用，告诉用户，你可以在这个地方加上具体本次修改的细节。

个人觉得他的缺点是：
就是你所着的工作要和task关联，并且激活正确的task（有时候偷懒，完成一个Task后不立刻切换到下一个task。－－这个习惯不太好：（）。他就不能正确的给出默认注释了。

我们要写入的条目有：
针对的bug号（或任务）
原因（是什么导致的bug)
解决办法（怎么修改的）——我的理解是，这样写有利于知识积累，以后遇到类似的问题时可以查看
验证方式（别人怎么测试来验证你实现了功能或修复了bug）
提交记录的链接——ViewVC的url，重点是对应的revision号
另外最好写一下，影响到的功能

不知道别人是怎么做的，交流一下？

提交注释写的清楚，以后维护代码就很方便了。

这帖子要不要精华？

>我们要写入的条目有：
>针对的bug号（或任务）



>原因（是什么导致的bug)
>解决办法（怎么修改的）——我的理解是，这样写有利于知识积累，以后遇到类似的问>题时可以查看
>验证方式（别人怎么测试来验证你实现了功能或修复了bug）
>提交记录的链接——ViewVC的url，重点是对应的revision号
>另外最好写一下，影响到的功能

>不知道别人是怎么做的，交流一下？

>提交注释写的清楚，以后维护代码就很方便了。
我觉得在代码注释里面加上相关任务在bugzilla（或其他相关系统）中的url就可以了。
因为有这个这个url以后，关于解决问题的方法、如何避免这些问题等，都可以在这里获得相关系统中写入。我觉得他们干这些活可能比svn更在行。还有就是这些系统一般都会体统相对比较完善的搜索机制。这个完全能做到方便其他人查看。

恩，我觉得你所提到的缺点恰恰是我对这种做法最困惑的地方：
1.你假定整个项目处于一个相对稳定的阶段，可以按部就班地对每个bug界定其对应的任务，然后围绕这些任务进行分派，修改，提交，写comment，问题是如果项目处于一个在需求以及设计上都不是特稳定的阶段（某些产品的预研版），对于很多bug修复，我也许很难将其归结到具体某一个个的task，这种情况如何处理呢？
2.mylyn结合bugzilla,方能使你的方案达到最大的效用，问题又来了，bugzilla在团队内推广以及使用契约，目前在我们团队又是个难题（大家一起鄙视我吧），一直尝试在推，但得不到太大的响应。

针对先前团队出现的问题，逐步有些改进思路：
1.尽量把所有需要修改的issue都能通过bugzilla集中管理；
2.给产品各个预研版以及使用到该产品的项目建立对应的分支，feature稳定后再合并到主干中；
3.预先制定一套comment模板（格式，作者，问题描述，解决问题的关键点，如何测试）。

再次感谢各位。

开始规范的问题