SVN分支管理模式与分支基础操作

·  阅读 638
SVN分支管理模式与分支基础操作

简介

本文对SVN的分支管理进行模拟记录,主要参考设计方式: www.cnblogs.com/huangjinyon…

策略描述

image.png

image.png

image.png

分支生命周期

dev主线开发分支,基本就一个分支,不会再打多个

feature根据需要的小功能去打分支,合并后删除

qa,测试分支,每次发包都进行合并,只需要一个分支

pro_cortp主线分支,由测试完成后分支合并过来,只需要一个分支

release线上发布版本,需要多个分支进行标记,十分浪费空间

fixbug,bug修复分支,依据修复的bug打分支,最后合并后删除

布局

主干(历史分支)

项目一开始时存放基本环境代码的分支,一般开发项目中,明确了开发所需工具所需环境后,搭建起来的一个分支,他面向开发人员,相当于内部的一个版本发布分支,由于它记录了整个项目的开发历史,我喜欢叫他历史分支

image.png

测试分支

项目的开始,由历史分支pro_cortp为基础创建出测试分支

注:这里对第一次出现的操作,如创建分支,合并分支等进行描述,后续重复操作不在描述

image.png

image.png

这样创建出来的分支是直接在云端仓库创建了对应的分支,记得进行一次更新操作

开发主线分支

开发主线分支直接以测试分支为基础创建出来,从测试分支创建出来可能会比较好理解,为什么?

你想想,主线分支是从测试分支分出来的,那主线分支开发完毕后,合并回测试分支,一点冲突都不会产生,你觉得原因是什么?

没错,由于主线分支是从测试分支创建出去的,而主线分支一直在开发,版本号比测试分支高,合并回测试分支的时候,对于测试分支来说其实是更新操作。还需要注意一点,合并是需要有祖先关系存在的。

image.png

开发分支

这一分支其实灵活性是非常大的,甚至可以不使用该分支,直接以主线分支为基础进行开发,但是在你需要以功能或其他一些可定义的途径为单位去定义整个项目的开发时,你就可以使用到该分支,它会让你的项目开发过程看起来更有条理性。

image.png

开发

现在一切准备就绪,可以开始开发了,依据项目,划分对应开发主线分支,开发分支,各个人员接到任务进行开发,提交,当一个阶段开发的差不多的时候我们要开始分支管理最让人感到恐惧的一步,分支合并。

开发分支间的合并(合并操作讲解在这)

合并确实是一个让人较为难以理解的东西,但是其实也无需害怕,只要按照我推荐的合并方式,可以进行大胆的合并尝试,反正可以进行还原。

注意:禁止单个版本提交多分支修改!SVN其实是一个版本管理器,如果在一个版本中对多个分支代码进行改动,在合并的时候可能会出现你并不想看见的结果,比如合并后代码无变化等问题。

合并推荐工具:Tortoise SVN,就是大家常说的乌龟SVN

为什么不使用IDEA自带SVN?

IDEA里的SVN我没有找到对版本范围的合并,只能对两个树进行合并,因此我不推荐

这是准备从feature合并到dev的目录结构:

image.png

其中,说明文件为冲突问题,我对其中内容都做了修改,另外两个不同名文件代表主线开发与分支开发不同的功能实现代码,现在开始合并操作讲解

选择需要合并的主目录如图操作:

image.png

选择版本范围合并

image.png

选择对应要合并的分支目录,可以发现这里合并源是从远端获取的,因此合并不需要本地有对应源目录,但是本地目录建议更新到与远端一致的最新版本,再进行合并操作

image.png

这里建议先使用测试合并看看会产生的操作

image.png

image.png

这里很明显会出现冲突,直接双击对应的冲突进行解决即可

image.png

当解决完成后,会发现合并完成的代码其实是未提交的状态

image.png

没错,这一种合并其实是合并到本地,在提交之前随时可以还原,只需要在合并后,执行代码,测试一下合并项目是否有问题即可进行提交,如果出现问题可以回退操作,去排除问题原因

image.png

测试分支的合并

当开发完毕后,需要进行发包测试,其实就是以测试目录为主干对开发分支进行合并操作,且由于测试分支内文件都是用于测试,不会进行修改,这个合并相当于测试分支的版本更新,不会产生任何冲突

image.png

测试完毕,合并历史分支

这里的合并与测试分支的合并类似,由于测试分支是从历史分支上产生的,在测试分支完成测试工作确定当前版本要记录到历史分支上的时候,进行历史发布,也就是以历史分支为主干,合并测试分支,这对于历史分支来说也属于版本更新,不会产生冲突

image.png

发布线上版本

这一阶段的线上版本分支其实也就是以历史分支为基础创建一个发布分支,需要注意,这里建议每一个线上版本都进行版本的记录(也就是创建分支),虽然会浪费空间,但是可以做到里程碑形式的版本记录,

image.png

线上bug修复

对于线上bug的处理,其实有两种形式,如果不是特别紧急的bug,建议在主线开发分支上创建新的feature分支去进行处理,等待后续的版本更新进行统一修复。

反之如果是紧急bug,可以以release分支为基础打出一个fixbug分支,单独处理这一个bug,处理完毕后合并回当前线上版本,并且一定要合并回主线开发版本,至于历史分支可以等待主线开发的下一个历史版本完成后合并过来。

image.png

结语

以上为SVN分支管理模式的基本框架构建与使用,可以看出分支的合并只要遵循每个分支规划其职责,位于父子分支或者祖先分支间的合并依序进行,就可以做到有序的开发过程,只有在进行紧急bug修复时才会出现跨辈分支合并的操作。

狗头保命

本人处于实习阶段,以上为整理材料与自身操作后的一些总结,如若有误欢迎指正

分类:
开发工具
标签: