一．标准库结构
1.目录内容
trunk,branch-dev,release此3个目录存放源代码，构建脚本、测试脚本、说明文件、安装脚本，数据库脚本，第三方源代码等开发、运行环境；
2.开发流程
各组开发人员从branch-dev目录checkout源代码到本地进行开发任务,
在本地开发任务结束，”ADD”相应文件，勾选改动文件，然后提交到仓库“commit”,注意commit一定要填写注释，否则研发组长无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。
3.版本合并
branch-dev对应测试环境，release对应演练环境，trunk对应灰度和生产环境；应公司管理要求和实际情况，SVN版本合并工作由研发组长负责合并，运维人员避免操作源代码；
演练发布日，由研发组长负责代码合并：branch-dev合并到release;
灰度发布日，由研发组长负责代码合并：release合并到trunk;
4.打tags
release合并到trunk后，就对trunk主分支打tag,并保存到tags目录内，tag名称就是版本号，例如：V3.1.5。
二．Git代码迁移到SVN
- 在本地新建层级目录（图中红色边框结构）：
- Pull各服务最新代码(或clone)到本地：
- 在git服务本地目录中，切换分支，并把源代码复制到步骤1中新建目录，master--->trunk ;banch-dev--->branch-dev ; release--->release
- 把本地载有源代码的目录复制到SVN仓库相对应的服务编码目录下
三.SVN使用规范
1、使用自己的账户和密码
2、先更新（SVN Update）,再提交（SVN Commit）
SVN更新的原则是要随时更新（SVN Update），随时提交（SVN Commit）。当完成了一个小功能，能够编译并且通过自己测试之后，谨慎地提交。
如果在修改的期间别人也更改了SVN的对应文件，那么Commit就可能会失败。如果别人和自己更改的是同一个文件，那么Update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。
在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。
3、多提交（SVN Commit）
4、不提交不能通过编译的代码
5、每次提交(commit)必须书写明晰的标注
6、提交时注意不要提交本地自动生成的文件
7、慎用锁定功能
8、标记版本
9、管理员需对SVN管理的所有项目定期备份。