版本控制一直是我比较头疼的问题，开发人员乱提交一气，有了一点问题就修改提交，然后要求出版本，我们每天的版本多如牛毛，SCM好像根本控制不了版本，项目经理来说要发版本我们就只有听命行事，整天忙得像个兔子，不知道大家有什么好的办法来控制一下呢？

你的根本原因估计也是在开发人员乱提交一气上，本身就没有对代码提交进行规范管理，何来版本控制？

1。首先，应该说有点修改就提交，这是好事。起码说明你们的所有工作成果和历史变动都被记录了。我这有俩产品线还就缺这个，我还愁怎么改呢。

2。我觉得目前你们的库
A。缺乏规划，日常提交的区域和控制区域没分开，导致需要的版本频繁变更，其实你可以看看论坛里的旧帖，关于三库和类似的概念不少，大多可以解决你说的问题。
B。缺乏基线或里程碑定义，这个有一定改进难度，因为需要项目经理去定义，但CM有责任从大局的角度去指导经理尽量不要频繁发布，如果实在不行，就跟自己的领导沟通，建立公司级发布机制，把发布这块控制住。

个人觉得一天出几个版本是很正常的情况，软件正是在不断的改进更新中生成的，如果你们有基线，提交的时候有写注释，或者你们有一个bug追踪的工具跟svn集成，有明确日常提交区域，有版本号变更规则，我想你的工作其实是繁而不乱的。

谢谢callmechen的分析

是的，我们有基线，部分提交也有注释，版本号变更也控制了，其实我们的版本控制的还比较好，工作繁，主要是开发那边验证不充分就提交，导致一个版本会反反复复的重发好多次，我是想问问有什么好的办法来控制这个呢？

引用:

原帖由 jenny415 于 2008-10-21 17:14 发表
是的，我们有基线，部分提交也有注释，版本号变更也控制了，其实我们的版本控制的还比较好，工作繁，主要是开发那边验证不充分就提交，导致一个版本会反反复复的重发好多次，我是想问问有什么好的办法来控制这个呢？

我觉得你还要先搞清楚一个概念：提交不等于发布。

发布是需要编译和测试的，如果你能区分出提交和发布，测试那边就会先疯掉，测试经理如果签字同意发布，那才轮到CM去执行其它发布流程。

两方面抓：
1，加强单元测试
2，引入持续集成

一个DEV提交的代码应该是在本地通过了单元测试的。
一个发布的版本应该是经过了集成测试的。

我当然知道提交交不等于发布，但我们这边好像提交了就意味着要发布了。
而且我们这里也没有测试经理签字同意发布，每次都是项目经理说要版本，好那CM就去编译，然后发给开发自测，自测通过后发给测试部测试，至于发布给客户就不关CM的事了，项目经理或者测试部负责release给客户！

我觉得Piagodai的方法不错，谢谢！