在开发中比较头疼的一件事，版本控制属于比较重要的事情了，紧急程度随着线上版本的稳定性有所不同。但要做好版本控制，有些不同的困难需要解决。
之所以触及版本控制，考虑这种情况，线上运行版本处于稳定期，代码以修复bug为主，但是在主线上的开发要不断的添加新功能，代码库处于剧烈的变动状态，这就导致来了主线上的版本库bug率处于居高不下的状态，而且主线以新功能的添加为主，稳定性非常的差，但是这些还未经过充分review的代码，是不能添加进线上项目的。如果此时，线上运行版发现bug需要立即解决，那就只有从以往的版本库中找出线上版代码的序号，然后 在以往的代码中做修改，那正在开发的主线上的代码必须要随之做调整。如果线上版发现的bug比较严重，牵扯到了架构方面，需要做大范围的代码修改，那对正在开发新功能的主线版几乎就是种灾难。
对混乱的控制是非常有意思的挑战。版本控制本应是用于控制版本的变动的，但是如果使用不当再加上开发者素质不高，混乱是无法 避免的。
社区中对这种情况有一些比较有趣的讨论可以借鉴： 如何进行项目版本控制？
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：标准库存放位置
--------------------------------------------------------------------------------------------------
首先找一个切入点，定义主干。我项目把主干定义为：与正式库运行项目完全一致（就像正式系统的影子），目的是方便修改bug，排查问题。
当用户反馈正式系统有bug，那么就从主干上打出分支，在分支上改bug。待测试通过。把这个分支上线，同时主干合并该分支。其他分支合并主干（保证bug在svn范围内都被修复）。
若有新的需求准备开发，则在主干上打出新分支，在新开的分支上开发。
大体就是这样，这里有几点楼需要掌控：
开发前尽量估算出交付的时间，将交付时间差不多的需求，在一个分支上开发，减少分支数量。主干不允许任何人提交代码，除了合并分支。保证主干和正式系统的一致性。
---------------------------------------------------------
其实有一篇对于git版本控制的文章写的非常出彩，链接 http://nvie.com/posts/a-successful-git-branching-model/