git分支详解

git分支

1、git有一个中心仓库,库中有一个产品A的设计图纸,这个就是master。

2、码农A和B打算改进产品A;于是他们从仓库下载原始图纸到本地,然后在本地修改

3、码农A做出初步改进后打算提交,若其它任何码农均未提交,则可以直接提交;但却发现码农B已经提交自己的版本了

4、码农A认为自己的改进其实还有地方需要完善;那么如果每次合并主版本都要检查并合并B的修改(以及之后可能有的其它修改),显然会浪费很多时间,耽误后续开发;若草草检查就合入,就容易影响主版本的稳定。

5、于是码农A产生了一个分支,叫做产品A之码农A改进版;以后自己的改进都合进这个分支

6、码农B、C、D继续改进产品A的master版

7、N个月后,码农A认为自己的改进已经尽善尽美了,于是合并自己的“产品A之码农A改进版”到当前的主版本

8、但是两者冲突太多;于是码农A利用各种diff工具检查主版本和自己的分支版本之异同,注意观察自己的代码能否直接插入主版本而不引起逻辑故障;若不引起就合入,否则可能就要前后错几行、在合适位置合入。

9、合入后,经过重新测试,码农A就可以废止自己的分支版本,新功能开发完成。

10、任何参与开发的人,只要不是一次性修改,都应该这样开一个分支,把自己的工作先合入这个分支;等开发完全完成后再合并自己的分支到主版本。

以下是两个具体的场景:

在这里插入图片描述
假设有两个程序员A和B一起工作,A一开始每次提交都把工作逐渐成功提交到线上去,然后B提交了一个版本,导致编译失败了。这时,A就无法提交,因为提交就会挂,要等待B修复问题才能提交,这时A的提交和B的工作就产生了冲突。

第二种情况,多个分支往同一个分支合并,FeatureA先合进主干,FeatureB晚了一点结果发现无法合并,因为基线不一样了,这时候必须先解决掉代码冲突才能合进去。

4中常见开发分支模式

主干分支

在这里插入图片描述
团队人很少(比如1~2个人)的时候,最常见的研发模式是Trunk—BasedDevelopment,也叫主干开发方式。

主干开发方式一条主干分支走到底,开发的过程中不会有太多的冲突,要求代码持续集成到主干上去,所以在开发过程中不需要做相应工作的隔离。开发的过程中,所有的开发者在主干上面频繁地提交,频繁地集成。这种分支模式下,唯一的分叉出现在发布的时候,为了能够把发布版本隔离出来,有了发布分支。

这种模式下,不需要做分支隔离,信息同步通过持续频繁地提交来保证。在人数比较少,并且整个工程能力比较强的时候,这是我们推荐的研发模式。

Git-Flow

在这里插入图片描述
Git—Flow的基本原则是需要什么分支就给什么分支,任何事都有很明确的分支。比如说要集成,就有develop分支,要开发就有feature分支,要发布有release分支,每个都是不同的分支。每种类型的分支都有确定的用途。

比如说feature分支,是很多个feature并行开发的时候用来去做工作隔离,避免彼此之间有冲突。而release分支是用来做发布的隔离,使得发布之间不会有冲突。

我们发现这种模式很好地做了隔离,但是在信息同步的过程中,它需要基于develop频繁地集成去做同步,并且在各个分支中间做相应的cherry-pick或者是rebase这样的方式来做的。

这个时候,我们就会发现分支太多,而且一个commit从feature开发到最终发布要经历好几个分支,其中分支的流转和merge规则非常麻烦。

所以Git—Flow也不是仙丹,过多的分支增加了分支管理的复杂度。还有如果Feature分支的生命周期特别长,它的合并耗时也会变得很长。而且Develop分支和Master分支同时存在,好像Develop分支的意义不是特别大。另外区分Feature分支和hotfix好像意义也不是特别大。

GitHub-Flow

在这里插入图片描述
GitHub引入了一个分支模式叫GitHub—Flow,明显比Git—Flow简单很多。没有Develop,没有hotfix,也没有Release,当需要开发的时候拉一个Feature分支,开发完就合并Master做发布。

这个过程中,它的隔离只发生在开发过程中,它的信息同步通过持续地往Master去做集成,和频繁从Master里面Pull代码来实现。它的发布过程是基于主干Master分支做的,因此没有在发布的过程中做相应地隔离。

这时候又会带来一个问题,就是Master分支需要做持续集成,这个分支既是集成的地方也是发布的地方。一旦集成后出现问题,它会把所有的工作堵塞掉,无法发布也无法合并。

所以GitHub—Flow很简单,可以做相应地隔离,但是如果说本身基础设施或工程能力比较弱,它会限制你集成和发布的频率。

GitLab-Flow

在这里插入图片描述
GitLab—Flow和GitHub—Flow区别是在发布过程中有了Pre-production分支和Production分支,基于开发、集成和发布过程中不同的环境分配了相应的分支。

完成集成以后是在Master分支上,下面一步将会切换到预发分支上。对应Commit的版本已经达到了预发的条件,在预发上做完验证以后再将其同步到Production分支,说明它已经达到了发布的条件,所以它是逐级Promotion(晋级)的过程。逐步从集成的环境Promotion到预发环境,再Promotion到生产环境。

我们简单地介绍了一些常见的分支模式,下面我们再来比较一下他们之间的优劣。

常见分支模式优劣对比

在这里插入图片描述
TBD分支少,实施简单,做起来不需要太多的理解成本。但是它对团队协作的成熟度和纪律都有很高的要求,一旦有人不遵守纪律,那主干就会成为你的梦魇,这时就很难很好地去做持续地集成和发布了。一旦它出现问题,所有人都被Block,这是主干方式的优缺点。

Git—Flow特性之间可以并行开发,规则很完善,每个分支的职责特别明确,再大的团队协作基本上也不会有太多的问题,但是它分支太多,规则太复杂,而且分支生命周期长,合并冲突会比较频繁。尤其是Develop,Master是长期存在的。

对于GitHub—Flow,Git—Flow能支持的基本上它也能支持,但是这里面有一个问题,它的集成只有在Master分支去做,因此对集成纪律有很高的要求,而且集成和发布在一个分支上,一旦集成分支中断,无论是集成还是发布都会被中断。

Gitlab—Flow也是并行开发,但是开发分支还是会有生命周期长的问题,有合并冲突的风险。另外,发布分支之间是有耦合的,比如说Prodution和Pre—Prodution之间,是基于Promotion来耦合,所以彼此之间也是一种中断阻塞的方式,而且很多的开发分支,Prodution和Pre—Prodution,也增加了分支管理的复杂性。

因此,我们发现没有哪个分支模式是绝对好的,也没有哪个是绝对差的。

对于分支有一个简单的原则,即控制分支数目,小批量频繁集成。控制分支的数目也就是做到工作隔离,但是又增加太多管理成本。而小批量频繁集成可以加速信息同步。

所以一个简单的原则就是,从最大化生产力和最小化风险的角度,尽可能地控制分支的数目和小批量频繁集成。

最大化生产力:所有人工作在公共区域内。除了一条长期的,不被中断的开发主干外,没有任何分支。也并无其他规则,代码的提交过程相当简单。但是,每一次的代码提交,都有可能破坏整个项目的集成,进而导致项目进度的中断。

最小化风险:所有人都工作自己的分支上。每个人的工作是相互独立的,没人可以打断其他人的工作,这样,减少了开发被打断的风险。但是,这种做法却增加了额外的流程负担,同时,协作变得非常困难,所有人都不得不谨小慎微地合并自己的代码,即便是整个系统中非常小的一部分,也是如此。

  • 17
    点赞
  • 106
    收藏
    觉得还不错? 一键收藏
  • 3
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值