00:00
大家好,我是na killer,欢迎观看我的系列视频,本视频是nightt killerwas手札电子书的配套视频,喜欢我的电子书跟视频请动动手,点点小红心。本期视频学习的重点是分支的用途、软件的版本以及分支的用法。在版本控制当中,分支跟环境是密不可分的,而各种环境的发布以及部署又跟三个部门密不可分,分别是开发、测试跟运维。所以我要先讲一下开发、测试跟运维三个部门之间的关系,开发、测试、运维并不是三个独立的部门,他们是相互紧密联系但又相互制约的,类似于西方提出的三权分立的思想。开发只负责写程序,将运行无误的程序提交的版本库,开发人员是不能私自将程序交给运维部门去部署的,也不能私自将开发好的程序交给测试人员去测试,测试部门只能从版本库中提取代码,然后自行的编译打包运行,最后测试,测试人员是不能直接向开发人员索要编译好的代码,也不允许测试人员将测试好的代码交给运维这边来部署。我们要避免代码没有经过版本库流入生产环境,这会造成线下跟线上代码不一致的情况。运维部门负责部署应用程序跟配置管理,只接受测试无误的版本,并且只能从版本库当中提取代码。开发、测试和运维三个部门的关系现在已经讲的很清楚了,接下来我们要先创建一个项目,为后面的学习初始化一个环境。
01:56
这里是创建一个空项目,创建项目后,我们会初始化项目的标签,这里自动生成了一批标签,我们把当前这个标签改成任务,其他的标签也可以修改,我们暂时不做修改。标签创建完以后,我们进入议题创建里程碑,我们可以一个月作为一个里程碑,也可以一周作为一个里程碑,我们把开发计划写到里程碑里面。项目创建完成之后,我们就可以进行分支的学习了。
02:47
下面我就介绍一下常用的分支以及用途。我们常用的分支通常有三个,分别是开发、测试跟生产。这三个分支可以覆盖到90%的需求,规模稍大一点的团队还会加入sta分支,我们通常称为u at分支,也就是说用户交付、测试。上述的每个分支都会对应一个环境,所谓的环境就是一个物理机或者是容器。我们使用持续集成和持续部署的技术,将不同的分支部署到他们对应的环境当中。持续继承是通过代码合并来出发的,所以代码合并是有流程的,通常是从开发分支合并到测试分支,再合并到u at分支,最终合并到master的分支,也就是生产环境的分支。前面所讲的分支用法,开发、测试跟生产三个分支使用起来并不复杂,但是对于我们国内的很多团队还是有门槛的。其主要的原因就是。
03:48
我们的团队人员比较年轻,工作年限通常是在三到五年左右,以很多人对版本控制这项技术并不是很了解,所以我们可以看到国内的很多项目当中很少会看到feature分支跟hot face分支。feature分支是新特性分支,也就是说每个任务或者每个功能为此创建一个分支,开发完成之后再将其合并到开发分支,也就是每个功能对应一个议题,每个议题就对应一个feature分支。hot fix分支是每个bug一个分支跟filter分支用法类似。下面介绍一下分支的权限,设置分支的权限是避免我们误删除或者限制某个分支只能用于合并跟push,不允许去修改里面的代码,开发、测试跟生产,还有T标签必须保护,不允许被删除。开发分支允许修改,也允许合并跟push。
04:48
测试分支只允许合并跟push,八次分支只允许合并跟push。下面我们就来演示一下如何创建分支,我们从master分支创建testing分支,再从测试分支创建开发分支,这样三个分支就创建好了。接下来我们做保护分支的操作,选择我们需要保护的分支,上面有三个角色,分别是维护者跟开发者,维护者是可以进行合并跟push的,开发者是允许修改代码的。
05:39
现在三个分支我们都做了保护,这时我们就不用担心分支被删除的情况,我们要把默认分支切换成开发分支,这样当代码被克隆下去的时候,默认是开发分支,因为我们的所有的开发工作都是在T发位置上进行的,或者在filter分值上进行。这里还要保护一下tag标签,Tag标签我通常是用V开头的,例如V1.02.0,所以我们保护V星这种正则表达式。
06:16
Tag分支就不就不会被删除。下面我用一张图展示所有的分支合并流程,推分支,从开发分支创建并且合并的开发分支。开发分支是我们的常规分支,它会向测试分支合并,然后再向u at合并,最终合并到我们的生产分支。master通常合并到master分支并且上线验证无误后,我们会创建给它一个标签,给它打一个版本号hot fix分支是用来热修复的,我们发现生产环境有重大bug,会立刻从master分支创建一个bug分支,我们将代码拉下来进行快速修复,修复完成之后合并到master的分支,这是会造成master的分支和开发分支的代码差异,所以同时我们也要向开发分支合并一次,这样在下一轮的迭代当中代码就会同步了。软件的版本,我们通常接触的软件版本是版本号预入V1.02.0。
07:21
实际上软件的版本有很多种命名方法,比如说阿尔法版本、贝塔版本。阿尔法版本通常是内部测试版本,通常是对应我们的testing分支的,而Beta版本通常是provail,也就是预览版或者是unstable不稳定版本,我们通常用的是stable跟release版本,也就是发行本,它通常对应的是我们的tag标签或者是master的分支。产生不同的版本,我们从不同的分支拿代码即可。下面介绍一下feature分支的用法,操作共分为六步,第一步是创建新题,第二步是从开发分支创建我们的feature分支,我通常使用议题的编号来作为分支的名称。第三步是获取分支代码,因为默认是开发分值,所以当我们克隆代码之后,要把它切换到filter分值。第四步是我们的开发工作。
08:21
开发完成之后,将代码提交到版本库,第五步,将代码合并到开发分支。第六步是测试无误后关闭议题。现在来为大家演示一下,先创建议题,写出题的名字以及描述指派给自己写一个截止日期,这里没有里程碑,可以创建里程碑,给他指定一个标签点这个三角,然后选择创建分支,默认它是二,就是对应议题的ID,我会在前面再加个前缀。
09:08
我们现在在里面随便修改点内容。提交,点击创建合并请求按钮,选择好我们合并的分支,点击比较按钮,会看到变化的部分,然后点击创建合并请求,注意这个复选框是删除分支,现在进入流水线,可以看到流水线已经在工作了,完成这个议题以后,我们把它关闭。
10:02
最后讲一下hot fix热修复分支,Hot fix分支的操作步骤跟前面分支是类似的,它多了一步,最终要把hot fix分支的bug合并到开发分支。
11:18
分支跟版本,今天就先讲到这里,喜欢我的视频请给我点赞转发,谢谢观看。
我来说两句