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

.........

对于建分支的方式，我实在是强烈的反对。
这样不是相当于纵容开发人员不负责任的提交么？？自己也不管那么多了，反正领导要牵头合并呢，到时候让我改什么再说。
而且，讨论合并的时候，开发人员干什么？？不可能不等合并完成就继续在下一个分支上为所欲为吧？？
这样也拖延了集成测试的时间（你们做每日构建么？），把痛苦留到了代码集成的时候。
可算是svn有个branch了。

上面似乎有很多人支持这种做法，我实在不能理解。。。

谁说领导牵头合并？你要负责把你的branch合并到trunk并且测试通过。这不是你的责任嘛？

楼主说的。
那为什么要提交到branch中呢？为什么不先测试通过，然后提交呢。我不知道你们遇到的情况是什么样的？（我很想了解，这样自己以后可以避免）
我是没发现这样做有什么问题。

SVN到底应该怎么用？如果连以下两点都不能做到，那最好首先审视一下自己的编程习惯：

1. 频繁提交，而不是做完一个模块，测试通过后，再一批提交

2. 根据项目情况划分合适的Branch，并在某些重要的节点上打Tag，Branch和Trunk之间的merge由项目的实际情况而定。

本地都不测试就频繁提交？

这种假设就不应该出现在程序员的思路里面，没测试的代码可以提交嘛？

我只是顺着downpour兄思路发出的提问

原则 先更新 再提交

    关于频繁提交这一点。我明白你的意思。如果一部分代码签出后到提交，这个过程持续的时间太长，肯定容易造成等自己提交时，发现一堆冲突。
   关于这个，我认为可以从任务的分配上来解决，每个任务前进的步伐要小一些。涉及到接口方面和核心实现的要由比较有经验的人来控制，如果接口有修改，要及时通知大家。

如果没完成，就频繁的提交，实在不是好的开发习惯。

关于第2点，没体验过。可能比较大的团队会用到吧。呵呵。