对重要的web项目最好是使用主干+分支来进行版本管理。
在我负责的项目中，用上述方式管理web项目代码 的好处：
1.及时的版本控制，项目组内成员可以在分支及时进行代码同步，不用担心影响生产环境。
2.项目某功能开发完毕后，通过merge+commit+update操作，可以快速向线上环境 发布代码。
3.有利于权限分割，比如前端人员只 在分支目录有读写权限。
生产环境 目录读写权限分配给运维人员+后台人员就可以了。
实际应用：
主干目录：/respo/trunk/project_name/
分支目录 ：/respo/branches/project_name/
1.1 主干（trunk）：
1.11 保持与生产环境同步，也即最新版本（head revision）是经过验证且正确的。在生产环境可以直接执行svn up进行更新部署的。
1.12 原则上不直接commit，所有的代码操作是通过merge 合并过来的。
1.13 没有严格测试过的代码不要向trunk提交。
1.2 分支（branches）：
开发环境，也即开发人员平时进行开发使用的分支。
1.3 标记（tag） :
标记重大功能改动，记录项目里程碑式的修改，原则上不允许commit。
常见问题：
1.冲突，无论内容冲突或树冲突
解决：
1.1 一般分配任务尽力避免组成员同时修改某一功能 。
1.2 修改后及时提交（commit） 。
1.3 .修改前更新（update）。
1.4 出现冲突后，要充分明白双方的修改造成冲突之处的原因，既是：对方为什么要这样改。编辑并解决冲突（resolved）。
2.未测试的代码发布到生产环境（trunk）
解决：
2.1 合并(merge)仅选择自己提交的版本
2.2 如果要合并其他人的提交版本，必须有充分的了解。
3.发布的代码遭遇内容回滚（版本号没有回滚）.也即：提交的代码被还原到旧的内容，但是版本号却增大了。
案例描述：
trunk
版本号 1： mb_convert_encoding($biz_content,’UTF-8//IGNORE’、’,’GBK’);
版本号 2 去掉 //IGNORE： $biz_content= mb_convert_encoding($biz_content,’UTF-8′,’GBK’);
此时主版本与分支内容保持一致。
过几天，网站报错。查看svn trunk：发现 已被还原为： mb_convert_encoding($biz_content,’UTF-8//IGNORE’、’,’GBK’);
并且版本号已经是版本 3。但分支并没有此修改，询问提交此代码者也说没有修改过此文件内容。
估计是由于：将已合并过的版本号1， 进行了二次合并，造成代码被还原。按理说已经合并的代码是不会二次合并的。
解决：
3.1 合并（merge）后，向主版本提交（commit）务必检查每一个文件是否是自己所做的修改。
