SVN分支管理策略个人见解

本篇目录

  • 前言
  • SVN分支管理策略
  • VisualSVN Server
  • TortoiseSVN客户端
    • Repository的创建
    • Check out
    • trunk创建新项目MyProject
    • trunk更新提交更新,迭代版本创建Tag V1.0
    • 基于Tag的Hotfix Branch
    • Hotfix Branch改动Marge(合并)到trunk中同时创Tag_V1.1进行发布
    • 定制化分支Customize branch
  • 总结

前言

使用svn做为源码管理工具已有几年,但一直都只是使用到了trunk。最近项目中发版本每次都会将一个版本的文件拷贝打包为rar压缩文件,下个版本迭代则重新在svn服务端创建新的Repository用于管理。显然这tag版本脱离了svn的管理,日志记录也会发生断层。

于是最近就查阅了一些文章,结合实际对 trunk、tags、branches 进行体验操作,有点收获,怕以后忘了,故做此记录。

SVN分支管理策略

其中

Trunk:主开发分支,所有最新的代码都在这里。

Tags:一个里程碑版本,一般都可保证直接上线(名字:”V1.0”,”V1.1”,”V2.1”,”School_V1.0”,”School_V1.1”…),用于存放发布的版本。

Hotfix branch:修正bug的分支(名字:”hotfix_V1.x”,” School_hotfix_V1.x”, “School_hotfix_V1.x”),从需要修复的tag拉出分支,用于解决已上线版本的bug。

Customize branch:定制化需求的开发分支(名字:”School_Develop”…),用于定制化需求开发一个版本。

VisualSVN Server

服务端采用VisualSVN Server是免费的,而客户端VisualSvn是收费的,可使用免费AnkhSvn替代集成至Visual Studio使用。VisualSVN Server的下载地址:https://www.visualsvn.com/server/download/,VisualSVN Server的安装使用网上有很多文章,此处不做描述。

TortoiseSVN客户端

Repository的创建


Check out

首先Checkout在服务端repository创建的Test,默认创建了三个空文件夹。

trunk创建新项目MyProject

trunk更新提交更新,迭代版本创建Tag V1.0

提交迭代版本更新。

基于trunk中最新版本创建Tag_V1.0。在/trunk/MyProject目录上右键,依次选择"TortoiseSVN" -> "Branch/tag...",在弹出窗口的"To path"中填入tag的地址。

提交后在文件夹更新后会在Test\tags文件夹下出现MyPro_V1.0文件夹,tags目录下的MyPro_V1.0文件夹就是以trunk中指定的版本拷贝的副本做为版本V1.0进行的封存。

基于Tag的Hotfix Branch

当版本V1.0发布上线后,出现线上bug后需要修复,则以Tag中MyPro_V1.0创建Hotfix Branch(步骤和创建Tag类似),在Hotfix的分支中修复问题。修复完成后需要将此次的改动Marge(合并)到trunk中同时创Tag_V1.1进行发布。

提交后在文件夹更新后会在Test\branches文件夹下出现bugfix_by_account文件夹,在此基础上修复问题并提交。

在/branches/bugfix_by_account目录上右键,依次选择"TortoiseSVN" ->"Revision graph",在弹出的窗口中可以看到版本分支图。


Hotfix Branch改动Marge(合并)到trunk中同时创Tag_V1.1进行发布

在/trunk/MyProject目录上右键,依次选择"TortoiseSVN" ->"Merge...",

点Next出现如下窗口,

如果trunk中的版本修改过的文件与Hotfix分支中的修改不重合则不会产生冲突。下图是trunk进行过版本提交,与Hotfix分支中的修改产生冲突。

点击 Edit Confict解决冲突。

冲突处理完后点击Resolved,冲突解决完成本地trunk中已包含Hotfix分支的内容,合并后需要提交至svn服务器。

Hotfix分支修复完成后创建Tag_V1.1与之前trunk创建Tag_V1.0类似。

完成以上动作后的版本分支图如下。

定制化分支Customize branch

定制化分支使用的方式和之前创建branch方式类似,在此不做赘述。

总结

合并发生在本地working copy,只要你不提交就不会影响到repository。

合并前一定要先update、commit,保证不会out of day,并将本地的修改保存到repository。

使用svn创建的分支都会在指定的文件夹中创建副本,如果是在不同的分支文件夹中开发时候需要重新对项目配置(eg:IIS外部主机),也可在trunk中切换分支则不用修改配置,但是svn服务端需要保持可连接状态。

时间: 2024-12-14 13:26:07

SVN分支管理策略个人见解的相关文章

GIt分支管理策略

大纲: 1.前言 2.创建分支 3.切换分支 4.合并分支(快速合并) 5.删除分支 6.分支合并冲突 7.合并分支(普通合并) 8.分支管理策略 9.团队多人开发协作 10.总结 注,测试机 CentOS 5.5 x86_64,Git 服务器版本:git version 1.8.2.1,客户端版本:git version 1.9.2.msysgit.0.所有软件请到这里下载:http://msysgit.github.io/. 1.前言 在上一篇博客中我们主要讲解了Git 远程仓库,相信大家对

分支管理策略

通常,合并分支时,如果可能,Git会用“Fast forward”模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用“Fast forward”模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下--no-ff方式的merge: 首先,仍然创建并切换dev分支: $ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt文件,并提交一个新的commit

[转]Git分支管理策略

如果你严肃对待编程,就必定会使用"版本管理系统"(Version Control System). 眼下最流行的"版本管理系统",非Git莫属. 相比同类软件,Git有很多优点.其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便.有些传统的版本管理软件,分支操作实际上会生成一份现有代码的物理拷贝,而Git只生成一个指向当前版本(又称"快照")的指针,因此非常快捷易用. 但是,太方便了也会产生副作用.如果你不加注意,很可能

Git工程开发实践(四)——Git分支管理策略

Git工程开发实践(四)--Git分支管理策略 一.Git版本管理的挑战 Git是非常优秀的版本管理工具,但面对版本管理依然有非常大得挑战.工程开发中,开发者彼此的代码协作必然带来很多问题和挑战:A.如何开始一个Feature开发,而不影响其它Feature?B.由于很容易创建新分支,分支多了如何管理,时间久了,如何知道每个分支是干什么的?C.哪些分支已经合并回了主干?D.如何进行Release的管理?开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时

SVN 分支管理

平时在工作中使用 SVN 只是限于 commit,update 这样的操作,没有用过分支管理.开发过程中一般都是一个功能开发完成之后整体进行提交,而最近在项目中有一个比较大并且开发周期比较长的功能,所以在功能没有完成之前不方便进行提交,所以想到了使用分支管理,边学边用(所以工作最好一定要选开发流程规范的公司). /*环境: * 服务器操作系统 - CentOS 6.6 * SVN 服务器 - Subversion 1.6.11 * 客户端操作系统 - Windows 10 64位 * SVN 客

[廖雪峰] Git 分支管理策略

通常,合并分支时,如果可能,Git 会用 Fast forward 模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制 禁用 Fast forward 模式,Git 就会在 merge 时生成一个新的 commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下 --no-ff 方式的 git merge: 首先,仍然创建并切换 dev 分支: $ git checkout -b dev Switched to a new branch 'dev' 修改 readme.txt

GIT 分支管理:分支管理策略、Bug分支、Feature分支

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下--no-ff方式的git merge: 首先,仍然创建并切换dev分支: $ git checkout -b dev Switched to a new branch 'dev' 修改readme.txt文件,并提交一个新的commit

Git分支管理策略(转)

如果你严肃对待编程,就必定会使用"版本管理系统"(Version Control System). 眼下最流行的"版本管理系统",非Git莫属. 相比同类软件,Git有很多优点.其中很显著的一点,就是版本的分支(branch)和合并(merge)十分方便.有些传统的版本管理软件,分支操作实际上会生成一份现有代码的物理拷贝,而Git只生成一个指向当前版本(又称"快照")的指针,因此非常快捷易用. 但是,太方便了也会产生副作用.如果你不加注意,很可能

git 教程(15)--分支管理策略

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息. 如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息. 下面我们实战一下--no-ff方式的git merge: 首先,仍然创建并切换dev分支: 修改readme.txt文件,并提交一个新的commit: 现在,我们切换回master: 准备合并dev分支,请注意--no-ff参数,表示禁用Fast for