协同开发中SVN使用

概述

本次SVN提交规范主要针对当前项目中出现的SVN管理难，开发流程控制难掌控，项目进度记录不准确等问题而提出。

规范

目标，要求

要求每个角色都要进行规范化SVN作业。

目录结构与开发模式

分散式分支开发模式原理

     Svn://project/
                                           +trunk/（主开发目录）
                                           +branches/（分支开发目录）
                                                                                +dev_1.0_function1（功能性分支1）
                                                                                +dev_2.0_function2（功能性分支2）
                                                                                …
                                           +tags（存档目录，不允许修改）

• 1.0的开发，做一个dev_1.0的功能性分支

  Svn://project/                                                                  
                                           +trunk/（不承担开发任务）
                                           +branches/
                                                                                +dev_1.0_function1
                                           +tags
  

• 1.0功能开发完成，合并分支到主干

  Svn://project/                                                                  
                                           +trunk/（merge from branch dev_1.0_function1）
                                           +branches/
                                                                                +dev_1.0_function1（开发任务结束，冻结）
                                           +tags
  

• 测试完成，根据主干做一次1.0的tag

  Svn://project/                                                                  
                                           +trunk/（merge from branch dev_1.0_function1）
                                           +branches/
                                                                                +dev_1.0_function1（开发任务结束，冻结）
                                           +tags
                                                                                +tag_release_1.0（copy from trunk）
  

• 1.0版本结束，做下一个版本的开发2.0

  Svn://project/                                                                  
                                           +trunk/（merge from branch dev_1.0_function1）
                                           +branches/
                                                                                +dev_1.0_function1（开发任务结束，冻结）
                                                                                +dev_2.0_function2（2.0的开发）
                                           +tags
                                                                                +tag_release_1.0（copy from trunk）
  

• 1.0版本出现bug，直接在dev_1.0版本上修复

  Svn://project/                                                                  
                                           +trunk/（merge from branch dev_1.0_function1）
                                           +branches/
                                                                                +dev_1.0_function1（bugfix）
                                                                                +dev_2.0_function2（2.0的开发）
                                           +tags
                                                                                +tag_release_1.0（copy from trunk）
  

• 选择性的进行代码合并

  1,在dev_1.0版本上修复完成后需要同步合并代码到其他的开发分支上去
  2,需要合并到主干然后重新打包上线一个版本用于修复线上紧急bug
  

使用规范

命名规范

• 分支名称采用固定名称与下划线结合方式进行功能性分支描述如:dev_1.0_crm。
• 存档名称统一采用tag_release_版本的方式。

提交规范

提交之前先更新

在每次提交文件的时候，先进行必要的更新操作，因为，有可能在你修改文件的期间，别人也修改了同样的文件，那么本次的提交很可能会失败。

保持原子性的提交

每次提交的时间尽可能的短，如当你修改了UI界面，完成了功能小细节，确认了bug完善就提交代码。

不要提交本地配置文件，自动生成的文件，自己不明白的文件

本地环境因人而异，因此就有了不同的配置文件，缓存生成文件等，在提交的时候，尽可能检查提交的内容是否是包含了类似不必要的文件。

注释规范

每次提交必须书写明晰的标注

在项目中，如果没有注释，会导致管理人员不能清晰的把握每次的项目提交的概要，bug管理与文件不对称，难以掌控项目的进展等问题，因此建议填写注释，同时不能填写一些无效，无用的信息。填写好的注释应该是能概要的描述所提交的文件的基本功能的信息，也建议使用下面的规范。

注释规范写法，提交前加注释标签

• Todo： 任务清单
  对于需求性的功能使用todo前缀标签，如加入经纪公司模块，使用类似以下语句：Todo： 增加经纪公司模块
• Bugfix:： bug修复
  对于系统bug,等信息提交前加上bugfix标签，如修复待遇显示不正确：Bugfix: 修复期望工资待遇显示错误bug
• Junk: 零碎碎片
  其他的一些无效的信息修改

---

Android Studio 使用 SVN 代码分支管理使用示例

安装SVN客户端

添加项目提交管理忽略的文件

image.png

• 第一个和第二个是默认存在的，也就是本地项目工程配置相关内容。保持不变；
• local.properties：一些系统配置，例如SDK位置，NDK位置等；
• .gradle：相关配置文件；
• .idea：存放项目的配置信息，包括历史记录，版本控制信息等；
• build：该目录下有大量临时文件，这些文件会在build的时候创建，相当于eclipse的bin目录；
• app/src/test：测试文件；
• .iml：编译后自动生成，其中内容有一些本地信息，不同电脑上会不一致。

上传项目到svn

image.png

image.png

image.png

image.png

创建分支

在项目上 右键->subversion->branch or tag 进入create branch or tag界面如下：

image.png

image.png

最终我们看到的分支明细是这样的：

image.png

切换分支 （一定是本地先提交再切换分支）

在项目上 右键->subversion->update directory ... 进入update directory 界面如下：

image.png

点击use branch后面的"..."来选择分支，如下：

image.png

如果有多个分支，点击第二条（"guider..."）就可以查看更多分支了。

image.png

分支合并

分支合并的顺序一般有几种

• 功能开发分支 >合并到测试分支（或者直接合并到主干）
• 线上版本tag1.0 作为线上版本bug 修复> 合并到主干及分别合并到其他功能开发分支 一般tag 不允许修改，也可从上线tag 打出一个分支出来作为修复线上bug 分支 然后进行以上操作合并
• 功能分支之间的合并 常见于我们项目周期不同步，例如 医学网 自考网 与 会计网不同步功能

合并分支一定是代码在当前分支 然后进行 从其他分支合并到当前分支来进行操作

如图我将其他分支合并到该master开发分支上来

image.png

image.png

有冲突解决冲突 然后提交即可

还可以这样操作

image.png

image.png

一般我们会重复进行分支合切换 分支合并 解决冲突 提交 合并分支的操作

参考：

• SVN 和 Git 在日常使用中的明显差异 https://github.com/xirong/my-git/blob/master/why-git.md
• SVN常用命令 https://www.jianshu.com/p/c47f2931cba2
• Git代码管理 https://www.jianshu.com/p/acc495c32c4b