背景
在工作的过程中,git管理方式已经成为每一个项目开发的基础,每个项目的开发都离不开git管理方式。
但是在使用的过程中,由于对git分支管理方案的了解不深,导致会出现分支管理不明确的情况。
本文主要是做科普作用,看看主流的分支管理方式以及分析管理方式的不合理之处。
基础知识概述
在Git分支管理中,主要可以分为以下两类分支:
-
主要分支
-
master(主分支)
-
develop(开发功能分支)
-
-
支线分支
-
feature branch (功能分支)
-
release branch (预发布分支)
-
hotfix branch (热修复分支)
-
在开发的过程中,master分支就类似于一棵树的主干,而其他分支就是在这棵树上的主干所分出来的分支:
流程图
为什么需要一个合理的分支管理方案,我们可以举个例子来进行论证。
分支管理的Bad Case
情景再现:
首先,PM发来需求,有个项目要开始了,版本号为V1.0。
此时我们开开心心收到需求后,开始切分支进行开发:
经过老老实实的开发,测试,我们的在绿色节点的位置完成了项目的开发,目前一切顺利。
此时,PM发来了新的需求,我们需要开始做V2.0了。
收到需求后,我们又认认真真、老老实实的在V1.0的基础上,拉出来了分支,开始了开发:
在顺利的开发、测试过后,我们也顺利的把V2.0给Release出来了,目前看来还是一切顺利。
接下来我们在PM的安排下,开始了V3.0的开发,还是老样子,拉分支开始开发:
在开发的V3.0过程中,PM传来消息:V1.0当中出现严重bug,需要修复,此时我们转向修复bug,在V1.0的基础上,拉出来BugFix分支,开始修复bug:
经过华丽的操作之后,我们完成了bug的修复,并且发布了V1.0的bug修复版本,此时我们发现bug的修复需要合并到其他的分支上,因此我们就需要:
通知所有的开发同学,把V1.0的最新commit合并一下,确保版本稳定。
然后大家就开始合并代码。
最后我们顺利的将改动全部合并到有影响的分支上,然后开始V3.0的开发。
经过开发,我们此时终于完成了V3.0的released发布,然后我们又开始了V4.0的开发:
此时又又传来消息,V2.0出现BUG,需要修复!然后我们又开始了V2.0的修复:
修复完毕后,我们又要告知其他同学:
通知所有的开发同学,把V2.0的最新commit合并一下,确保版本稳定。
一些敏锐的同学可能很快就能注意到,此时问题就出现了:
-
在此分支管理方案中,没有一个明显的、稳定的版本分支存在,每次开发同学在开发时需要时刻关注其他分支的稳定情况,若对自己的分支有影响,需要合并相关分支的代码。
-
若出现多个分支出现问题,需要每一个被影响的分支,合并所有的修改过的代码到自己的分支上,随着项目的进行,这种合并分支的代价会变得非常大。
-
在开发过程中,若忘记合并某一分支的bug fix,非常容易导致不可预期的问题出现。
很明显在该种方案下,我们很难去确认哪一个分支的哪一个版本是最新的、稳定的版本。
借此例子,我们来看看比较规范的分支管理方案是怎么样的。
规范的分支管理方案:
规范的分支管理方案如图:
在一个规范的分支管理方案中,有几个主要分支:
-
Master分支:用来保存稳定的,已经released的版本代码
-
Develop分支:用于开发,保存了开发过程中最新的代码
-
Feature分支:用来分功能开发,开发完成后将代码合并到Develop分支
-
hotfix分支:用来做Bug修复的分支
首先,在这种分支的管理下,我们上面的情景就会变成以下的开发形式:
情景再现:
PM告知开始开发V1.0版本:
(这里我们简化了Feature分支)
在开发完成后,我们将已经Released的代码、稳定的代码,合并到了Master分支。
然后开始了V2.0的开发:
同样的,我们开始了V3.0的开发:
PM也同样的告诉我们,V1.0版本有错误,请紧急修复!
我们就一样在Master的V1.0的基础上,拉出来fix分支,进行bug fix :
在Bug Fix完毕后,我们就把修复后的代码commit到Master上,确保Master上代码是最新的稳定的,然后我们就可以告知各位:
通知所有的开发同学,把Master的最新commit合并一下,确保版本稳定。
这样子的话能够带来几个好处:
-
避免了大家每次合并代码时,都需要去了解具体的,有修改的分支代码,只要check在Master上的分支代码有何差异即可。
-
以Master作为最新的最稳定的版本基准,其他同事参与项目的时候,只要拉master的最新代码即可开始开发,无需再次确认最新的稳定代码在哪个分支,减少沟通成本。
-
每次想同步代码只需要关注Master代码即可,减少信息差。
以上标准的分支管理模式在人越多的时候越能够体现它的优点。
最后
分支管理方案只是一个约定俗成的观念,并没有绝对的对错之分。
当然能用比较适合的分支管理方案,那自然是再好不过。