当前位置：首页 > 数据库

40 图 | SVN 开发流程优化

你好，流程我是优化悟空~

本文主要内容如下：

前言

最近和一个研发团队打交道的比较多，了解到他们的流程代码管理用的是 SVN 工具，不是优化用的 Gitlab。

SVN（Subversion）：集中式管理的流程版本控制系统，很多操作需要连上公共的优化 SVN 服务器才能操作，断网了则不能提交代码。流程简单易上手。源码库优化SVN 创建分支其实就是流程拷贝目录，非常昂贵。优化

SVN 集中式管理的流程示意图

Git ：是分布式管理的版本控制系统，很多操作在本地就能完成，优化即使断网了也能提交代码到本地分支。流程功能强大较复杂。优化很多操作支持离线操作。流程

Git 分布式管理的示意图

他们使用 SVN 来管理代码仓库已经很久了，而且只有一个代码分支。为了优化他们的开发流程，免费模板悟空整理了一版基于 SVN 的多版本控制的开发流程，其中借鉴了 Git 的版本控制的思想。

有同学可能会疑问：为什么不切换到 Gitlab？

因考虑到目前部署和安全等多个因素，暂时不会切换到 Gitlab ，需要一个过渡期。

接下来我们来看下用 SVN 如何做版本管理，如何优化开发、测试流程。

一、分支管理

SVN 服务的目录管理

branches 目录：存放非主干分支的目录，模板下载其中有一个 develop 目录作为开发分支，其他与 develop 的同级目录作为日常开发分支、Bug 修复分支、热修复分支。

因 SVN 的多个版本其实都是拷贝的原文件目录，所以版本不宜过多，代码包的整体大小不宜过大，控制在 100 M 以内。

trunk 目录：作为存放主干分支代码的目录

测试环境部署的是高防服务器 develop 分支，当测试环境验证通过后，将 develop 分支 merge 到 trunk 分支上。

另外我们没有用到 Tags 这个概念，为了降低前期的流程复杂度。

分支命名

因 SVN 没有类似 Gitlab 的 issue 功能，所以分支的命名是不带 issue id 的，用的日期作为标识。

trunk ：主干分支，不可重命名，云计算不可删除。

develop: 开发分支，不可重命名，不可删除。

功能分支：feature_{ 日期}_{ 功能}。如：feature_20220809_login。

bug 修复分支：fix_{ 日期}_{ 功能}。如：fix_20220809_login。

热修复分支（hotfix）：hotfix_{ 日期}_{ 修复功能} 。如：hotfix_20220801_loginBug。

二、日常开发流程

开发流程和基于 Gitlab 的流程类似，但是 SVN 的功能没有 Gitlab 功能强大，源码下载所以有些细节不太一样。

整理了两种风格的开发流程，方便查看。

列表形式

流程图形式

三、热修复流程

当生产环境遇到紧急bug 时，可以考虑基于主干分支 trunk 分出一个 hotfix 分支，改完后，先提交到 hotfix 分支上，然后将 hotfix 分支merge 到 trunk 分支上，生产环境部署和验证通过后，再将 trunk 代码 merge 回 develop 分支，保持 develop 分支和 trunk 分支一致。

热修复流程

四、特殊流程

4.1 冲突解决

两个开发人员对同一个文件进行修改，彼此代码出现覆盖的情况就称为冲突。在较短的时间内，两个程序员对同一个文件同一处代码开发，后上传的会覆盖先上传的。

分两种冲突情况：

（1）对同一文件不同的代码处进行修改

后提交者，先更新自己的本地 develop 分支，然后merge到自己的开发分支，他人的代码和你的代码都会保留下来，然后再提交自己的分支代码，merge 分支到develop 分支。

（2）对同一文件的相同代码处进行修改

与冲突的那位同事商量，是用他的，还是用你的

如果用你的，先备份自己的代码，然后 revert 自己的改动，获取最新的代码，然后将自己的所有改动都覆盖上去。

如果用他的，先备份自己的代码，然后 revert 自己的改动，获取最新的代码。然后将其他的改动更新上去。（需要手动改，不要改动冲突处）

五、开发流程演示

SVN中常用的概念和操作如下：

Repository（源代码库）：源代码统一存放的地方。Checkout（提取）：该操作用于从 Repository 中提取一份源代码到本地。Commit（提交）：该操作用于将修改代码后的代码提交到 Repository 。Update（更新）：该操作用于同步本地源代码与 Repository 中的源代码。

SVN 客户端工具：TortoiseSVN