关于代码版本管理提升开发效率的一些想法

1. 传统开发模式

所有开发人员down下主干或分支代码，一起开发，待整体开发结束后，提交代码，部署测试发布。

优点：

环境部署、上线次数相对少一些，节省了一部分工作量。开发人员开发时间较长，可以合理安排时间。

缺点：

所有功能等到一天上线，一个周期时间较长不利于及时验证功能点效果。响应慢，一个小需求也要随着大版本才能上。

2. 分支开发

每个人在开发新需求点或者优化点时，都去新down一个分支，开发完成后，可以与已完成的其他分支一起部署到测试环境上。

这时首先会从主干上打一个release tag,将release tag与测试的几个分支一同合并，合并过程中可能会有冲突，和其他分支开发人员协调好改掉即可。

测试环境发布到准生产环境时，又会从主干上打一个release tag2，和准生产上的分支进行合并，重打tag是因为担心线上有发布，代码不一致。 

正式发布时，只需将准生产合并好的分支合并到主干即可。

多人协同开发时，相互并不影响，极大地提高了开发效率和交付效率。缺点是当交付时间不一致，分支较多时，文件冲突会比较多。如果交付时间一致的话，可以使用共享分支的方式，新部署的分支共享之前已经部署好的分支和release tag合好的分支代码，只需解决他自己引入的分支冲突即可，而不像重新合并所有分支和release tag那样，解决所有冲突。

优点：每人开发自己的功能，不相互影响，开发好即可合并到主干并发布，不需要等待其他人完成一起合并发布。功能单独验证，一个需求对应一个分支，对应一个测试人员，需要测试人员点击通过，此需求才算通过，很好的管理了整个需求的落地。代码自动发布部署，节省了部署发布时间。每个人可以看到自己有几个开发项，完成情况，是否已发布到测试环境，也便于项目经理和测试经理去看去管理。从技术和管理上保证了大团队能够进行敏捷开发。

ps：使用subversion或git（版本控制工具）都可以很好的做到这点