内容简介:就像人心散,队伍不好带一样,代码版本多,分支也不好管当产品开发到一定程度后,多版本同时开发,各种热修复等等问题,势必会带来版本分支管理的问题。今天我们准备一起来看看第一种代码分支管理方案。
就像人心散,队伍不好带一样,代码版本多,分支也不好管
当产品开发到一定程度后,多版本同时开发,各种热修复等等问题,势必会带来版本分支管理的问题。今天我们准备一起来看看第一种代码分支管理方案。
这里要先强调一下,分支管理的方式各有千秋,不存在谁一定比谁好,只有谁比谁更适合你而已
热门的成功代码分支管理
这款人们的分支管理方案只要是从这篇叫 A Successful Git Branching Model 衍生出来的。很多企业的项目都是采用这种方式来进行管理。下面这张图涵盖了这种方式的各种分支设计:
这个模型基本能满足企业项目开发过程中遇到的各种代码版本管理的需求,下面尝试着把这种模型分解给大家讲讲:
咬住青山不放松
在上面的图中,大家可以看到有两个分支的名字被加粗了: master
和 develop
,这两个是分支当中的中流砥柱。
#### master
这是新建一个GIT repository之后的第一个分支。在这个模型中,master分支代表的是当前产品线上的版本,它的最后一个commit可能是已经上线了,或者已经经过QA/PD/PO 千万次折磨、分分钟可以上线的功能。换句话说,这条分支要做到 随时都可以上线的! 要是谁把一个开发了一般的功能提交到这个版本上去,有可能会被PO拉去祭天的! 所以如果有严格的权限管理的话,一般会把这个分支给锁起来,有且仅有上线的同事才有权限动它!
另外master的每次上线都会打一个tag,表明版本号是多少
develop
一般灵长类动物都敬畏祭天这样的操作,所以我们需要开辟一篇新天地来大有作为。为了和大部队保持一致, develop
的分支是基于 master
创建出来的
C:\githome\github\gitdou (master) (gitdou@0.1.0) λ git branch * master C:\githome\github\gitdou (master) (gitdou@0.1.0) λ git checkout -b develop Switched to a new branch 'develop' C:\githome\github\gitdou (develop) (gitdou@0.1.0) λ git show-branch -a --no-name * [develop] add httpUtil.js ! [master] add httpUtil.js ! [origin/HEAD] add httpUtil.js ! [origin/master] add httpUtil.js ----
最后的 git show-branch -a --no-name
命令的输出可以看到 develop
的分支是基于 master
创建出来的
如果项目不是特别大,版本管理也比较简单,那么master跟develop这两个分支就基本够用了
文体两开花
当项目稍微大一些的时候,会遇到各种各样的版本管理需求,但不一定每一种你都需要,当需要的时候可以再建立这些分支,比如有 features
, release
, hotfix
features
第一种情况比较常见,项目有很多同事并行开发,比如分了多模块给多个小组进行开发,如果各个模块都往 develop
分支上面丢,那么基本没办法做持续集成(Continue Integration)的操作。虽然最后集成的时候各模块一定会和谐相处的,但是在开发过程当中,不一定每一个commit都是向模块兼容,所以最好能每个模块都自行在一个旮旯捣腾,等最好确定能相亲相爱了,大家再杵到一块去。
这是我们可以基于模块创建各种 feature
分支,有关开发人员就在相应的分支上进行开发就行,等到各个功能分支基本完成了,我们再把这些分支merge到develop上面去
如果有了feature分支,那么develop分支基本就成了集成分支了
release
前面说了master分支代表着当前产品线上的版本,分分钟可以上线部署而不会导致祭天这种结局的。但这有些项目或团队有这样的情况,产品上线前要先部署到 准产品线
上去玩,内测一周左右,确定完全没有问题了再上到产品线上去。在内测的这一周,如果发现了有问题了,赶紧从develop分支进行修复,再上到 准产品线
来验证。如果我们用master分支来进行准产品线的部署,在内测的这一周发现问题,而这时我们的产品线上有紧急问题要fix,那么我们就无法直接拿 master
分支上线,这就做不到我们之前的承诺: master分分钟可以上线而不用祭天
所以我们可以创建一个release的分支来进行准产品线的部署和问题修复,知道确认完全没有问题了,我们再同步到master分支去上线
hotfix
做系统的哪可能没有bug!当产品线上 无辜
出现bug的时候,我们要去哪个分支做修复呢?
- master :显然不合适,产品线上由于设计或者考虑不周出现bug一般是不用祭天的,但如果因为这样,在master上面一通乱改,那就有可能要祭天了
- release:这个是给下一个版本用的呢。如果是上一个版本的话,那新增的修改就破坏了原来版本号的意义了,比如原来分支叫release-1.0.1, 那么加了这个版本还叫这个名字吗?
- developer: 如果还有一些其它正在开发的功能,那一会上线的时候就会连带这个也稍上去了!
- feature: 这就有点扯远了
看来上面这4种分支都不大合适,那就来款新的,就叫hotfix. hotfix分支是从master分支直接创建出来的,用来做一些产品线上紧急的代码修复,或者临时添加的小功能。开发人员直接在这个分支上进行开发,功能完成后直接上到master分支再上线。
记得每次hotfix上线后,要把功能同步回developer,再到各feature的分支上
以上就是关于 这款 成功的代码分支管理模型
的讲解,基本上能满足大部分企业大部分项目的代码版本管理的需求! 后面会介绍另外一块代码分支管理模型,是指我们公司的一种管理的方式,下回见!
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:- 一个成功的Git分支模型
- GIT - 代码分支管理模型之二
- 我与Git的那些破事系列(下)--分支模型
- 版本分支管理标准 - Trunk Based Development 主干开发模型
- Git分支相关操作
- 代码分支管理规范
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
有限与无限的游戏
[美]詹姆斯·卡斯 / 马小悟、余倩 / 电子工业出版社 / 2013-10 / 35.00元
在这本书中,詹姆斯·卡斯向我们展示了世界上两种类型的「游戏」:「有限的游戏」和「无限的游戏」。 有限的游戏,其目的在于赢得胜利;无限的游戏,却旨在让游戏永远进行下去。有限的游戏在边界内玩,无限的游戏玩的就是边界。有限的游戏具有一个确定的开始和结束,拥有特定的赢家,规则的存在就是为了保证游戏会结束。无限的游戏既没有确定的开始和结束,也没有赢家,它的目的在于将更多的人带入到游戏本身中来,从而延续......一起来看看 《有限与无限的游戏》 这本书的介绍吧!