分支管理方案

背景

在工作的过程中，git管理方式已经成为每一个项目开发的基础，每个项目的开发都离不开git管理方式。

但是在使用的过程中，由于对git分支管理方案的了解不深，导致会出现分支管理不明确的情况。

本文主要是做科普作用，看看主流的分支管理方式以及分析目前DumuTools上分析管理方式的不合理之处。

基础知识概述

在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合并一下，确保版本稳定。

一些敏锐的同学可能很快就能注意到，此时问题就出现了：

1. 在此分支管理方案中，没有一个明显的、稳定的版本分支存在，每次开发同学在开发时需要时刻关注其他分支的稳定情况，若对自己的分支有影响，需要合并相关分支的代码。

2. 若出现多个分支出现问题，需要每一个被影响的分支，合并所有的修改过的代码到自己的分支上，随着项目的进行，这种合并分支的代价会变得非常大。

3. 在开发过程中，若忘记合并某一分支的bug fix，非常容易导致不可预期的问题出现。

很明显在该种方案下，我们很难去确认哪一个分支的哪一个版本是最新的、稳定的版本。

借此例子，我们来看看比较规范的分支管理方案是怎么样的。

规范的分支管理方案：

规范的分支管理方案如图：

 

在一个规范的分支管理方案中，有几个主要分支：

1. Master分支：用来保存稳定的，已经released的版本代码

2. Develop分支：用于开发，保存了开发过程中最新的代码

3. Feature分支：用来分功能开发，开发完成后将代码合并到Develop分支

4. 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合并一下，确保版本稳定。

这样子的话能够带来几个好处：

1. 避免了大家每次合并代码时，都需要去了解具体的，有修改的分支代码，只要check在Master上的分支代码有何差异即可。

2. 以Master作为最新的最稳定的版本基准，其他同事参与项目的时候，只要拉master的最新代码即可开始开发，无需再次确认最新的稳定代码在哪个分支，减少沟通成本。

3. 每次想同步代码只需要关注Master代码即可，减少信息差。

以上标准的分支管理模式在人越多的时候越能够体现它的优点。

最后

分支管理方案只是一个约定俗成的观念，并没有绝对的对错之分。

当然能用比较适合的分支管理方案，那自然是再好不过。