最近新加入一个团队，出于部署和安全等多方面的考虑，他们代码管理工具用的是 SVN，然后就有了这篇如何用 SVN 做版本管理、优化开发和测试流程。更多详情可参考
介绍
- Repository：源代码统一存放的地方
- Checkout：用于从 Repository 中提取一份源代码到本地。
- Commit：用于将修改后的代码提交到 Repository
- Update：用于同步本地源代码与 Repository 中的源代码。
客户端工具：TortoiseSVN
SVN 版本管理
- SVN 目录管理
- trunk 目录：存放主干分支代码目录
- branches 目录：存放非主干分支代码目录，其中有一个 develop 目录作为主开发分支，其它同级目录作为其它日常开发分支，BugFix 分支等，也可根据人员来划分
SVN 的多版本是基于原文件目录的拷贝，所以版本不宜过多，代码包的整体大小不宜过大。
- SVN 分支命名
- trunk：主干分支，不可重命名，不可删除
- develop：开发主分支，不可重命名，不可删除
- person/feature/bugfix：从 develop checkout 出来的分支，开发完成后可删除
SVN 开发流程
总体上的流程是模仿 Git WorkFlow 的工作流程，但是 SVN 的功能没有 Git 功能强大，所以一些细节不太一样。
| 阶段 | 角色 | 操作/事项 |
|---|---|---|
| 准备阶段 | 开发组长 | 基于最新的 trunk Checkout 新的分支:develop 分支 |
| 开发阶段 | 开发组员 | 基于最新的 develop 创建新的开发分支，以 feature 或人员命名用来开发或修复 bug |
| 代码审查 | 开发组长 | Code Review |
| 合并分支 | 开发组员 | 提交代码，合并代发分支到 develop 分支 |
| 测试阶段 | 测试人员 | 部署 develop 分支到测试环境自测或联调 |
| 生产部署 | 测试人员 | 将 develop 分支合并到 trunk，并部署到生产环境 |
| 测试阶段 | 测试人员 | 生产环境测试 |
| 收尾阶段 | 开发组长 | 删除 组员 feature 或 bug 的分支 |
SVN BugFix 流程
Bugfix 流程跟开发流程类似
| 阶段 | 角色 | 操作/事项 |
|---|---|---|
| 开发修复 | 开发人员 | 基于当前的 develop 分支 checkout Fix 分支 |
| 代码审查 | 开发组长 | Code Review |
| 开发提测 | 开发人员 | 通知测试人员部署 fix 分支测试 |
| 测试阶段 | 测试人员 | 部署 fix 分支到测试环境测试 |
| 生产部署 | 组长、测试 | 先合并到 develop，然后在合并到 trunk，最后部署到生产环境 |
| 收尾阶段 | 开发组长 | 删除 fix 分支 |
代码冲突
两个开发人员对同一个文件进行修改，彼此代码出现覆盖的情况就称为冲突。在较短的时间内，两个程序员对同一个文件同一处代码开发，后上传的会覆盖先上传的。
分两种冲突情况：
（1）对同一文件不同的代码处进行修改
后提交者，先更新自己的本地 develop 分支，然后 merge 到自己的开发分支，他人的代码和你的代码都会保留下来，然后再提交自己的分支代码，merge 分支到 develop 分支。
（2）对同一文件的相同代码处进行修改
- 与冲突的那位同事商量，是用他的，还是用你的
- 如果用你的，先备份自己的代码，然后 revert 自己的改动，获取最新的代码，然后将自己的所有改动都覆盖上去。
- 如果用他的，先备份自己的代码，然后 revert 自己的改动，获取最新的代码。然后将其他的改动更新上去。（需要手动改，不要改动冲突处）
总结
之所以采用类 Git Work Flow 的方式管理代码，更多的是多个人员同时开发，每个人只负责一个分支，而不是同时在一个分支开发，更便于代码管理，此模式适合小团队开发，大型项目的多人开发 Git 更适合一点