版本控制问题(1)

问题描述

项目开发时有一个svn版本库，大家一起提交代码和更新,后续开发的差不多了，客户要求上线，但是上线以后会有bug，同时项目还有新的功能要开发,如果大家现在共用一个版本库的话，会出现新功能还没有测试完成，但是bug是要及时修复，所以要着急发版。 

所以如何控制版本库，能够及时的修改和修复bug，同时对于新功能的开发还可以有条不紊的进行，同时对于发版不会因为新功能的开发代码提交而导致bug即使修复完成了也没有办法发版（因为新功能还没有开发完，只是提交了部分代码）。 

问题解决

主要思路：开分支

参考解决1：主要侧重于清晰的文件目录结构划分

可以借鉴一下，我们项目管理方式。 
svn根目录 
Trunk：主开发目录。 
Branches：分支开发目录及测试目录，版本正式发布并生成tag后删除。 
Tags：已发布版本（包括补丁）的存档目录，不允许修改。 
Release：程序发布目录，含运行程序、升级脚本和标准库。由配置管理员在版本发布时创建。 

trunk 
Bin：运行程序存放路径。 
Control：第三方控件存放路径。 
Documents：产品开发文档存放路径。 
Management：项目管理类文档存放路径。 
Procedure：存储过程或包、初始化数据及视图存放路径。 
Script：数据库升级更新脚本存放路径。 
Sources：源代码存放路径。 
Tools：工具存放路径 

Branches 
一级目录为程序修改版本标识，二级目录的目录结构与trunk一致。 

Tags 
一级目录为已发布程序基线版本号，二级目录为子版本标志，比如BL表示基线版本，sp1表示对应基线的第一个大补丁版本呢，三级目录的目录结构与trunk一致。 

Release 
一级目录为已发布程序基线版本号，二级目录如下： 
Bin：执行程序存放位置。 
Bin\Doc：操作手册、安装手册及升级说明存放位置。 
Patch：补丁存放位置 
Procedure：存储过程或包、初始化数据及视图存放位置。 
Script：数据库升级更新脚本存放位置。 
Stddb：标准库存放位置

参考解决2：思路清晰明快

结合自己项目的情况，使用SVN分支方式如下： 
首先找一个切入点，定义主干。我项目把主干定义为：与正式库运行项目完全一致（就像正式系统的影子），目的是方便修改bug，排查问题。 
当用户反馈正式系统有bug，那么就从主干上打出分支，在分支上改bug。待测试通过。把这个分支上线，同时主干合并该分支。其他分支合并主干（保证bug在svn范围内都被修复）。 
若有新的需求准备开发，则在主干上打出新分支，在新开的分支上开发。 

大体就是这样，这里有几点楼需要掌控： 
开发前尽量估算出交付的时间，将交付时间差不多的需求，在一个分支上开发，减少分支数量。主干不允许任何人提交代码，除了合并分支。保证主干和正式系统的一致性。

参考解决3: 一个成功的Git分支模型

在本文中，我向大家介绍的是在大约一年前我为自己的项目(包括工作和私人项目)引入的且已被证实非常成功的一个开发模型(development model)。这段时间我一直想写点关于它的东西，但在此之前，我却从未能抽出充足的时间来完成这件事。我不会谈论项目的任何细节，只涉及分支策略(branching strategy)和发布管理(release management)。