Git分支管理策略方案分析与总结

前言

随着Git的流行，越来越多的团队在往Git迁移或者转型，在团队建设初期或者中期转型优化，合适的Git分支管理策略方案能够较好的提高团队的效率，节约人员成本，降低代码版本管理带来的风险。笔者曾经历过因为分支管理策略不合适、人员操作不规范引发的代码版本混乱、线上版本与生产版本不一致等问题。本文旨在对几种Git分支管理策略进行梳理总结，对适用场景做探讨分析。同时非常渴望各位提出指正问题，共同沟通探讨更适用的解决方案。

内容概要

本文将通过对Git Flow、GitHub Flow、GitLab Flow三种流行的工作流程模型进行分析，总结各模型的优缺点与适用场景

Git Flow

流程分析

Git Flow模型声明了以下5个分支：

• Master 与生产保持一致，同时也是发布的分支（需要严格控制合并权限）
• Develop 基于Master检出的开发分支，保持最新开发进度的稳定分支（需要控制合并权限）
• Feature Branch 基于Develop检出特性分支，用于功能开发的分支，完成功能开发后合并到Develop分支
• Release Branch 基于Develop分支检出的预发布分支，用与预发布测试，测试完成后合并到Develop，合并到Master发布，合并时需要标记版本Tag，用于区分历史版本，合并完成后删除
• Hotfix Branch 基于Master检出的热点分支，用于修复生产bug，修复完成后合并到Develop，合并到Master发布，标记版本Tag

开发流程简述

单个需求开发：

1. 默认存在Master，Develop分支，在工程初始化阶段基于Master检出Develop（前置工作）
2. 此时开发人员收到需求需要开发A功能，从Develop检出Feature—A用于A功能的开发
3. A功能开发完成，将Feature—A分支合并到Develop分支，并进行初步的测试
4. 从Develop检出Release-A分支用于测试，用于回归测试，并且修复bug
5. 将测试好的Release-A分支合并Develop，合并到Master发布，并打上版本标签
6. 当生产出现bug时，从master检出Hotfix-fixbug分支修复bug，修复后合并到Develop，合并到Master发布，并打上版本标签 多个需求并行开发： 与单个需求开发的步骤基本一致，但要在合适的时间将Develop再合并到特性分支，避免多个版本交叉影响的风险（比如A功能的修改，对B功能的修改也有影响，此时应在A合并Develop后，主动将Develop合并到Feature—A，如果有问题，提早暴露解决）

特殊场景分析

场景1：计划功能A与功能B在某个时间点要同时上线，并且已经合并Feature—A、Feature—B到了Develop，将要检出Release分支进行测试，但此时收到通知，只上功能A不上功能B，此时Develop却包含了Feature—B的代码 解决方案：回滚Develop到上一版本，重新合并Feature—A到Develop

优缺点分析

优点:

• 功能分支独立，互不干扰，可以独立开发、测试
• 当Feature分支较长的时候，可以避免提前进Release
• 具备多个版本发布的能力

缺点:

• 模型相对复杂,维护了Master，Develop两个基准分支,当回归或者生产出现bug时，合并Master的同时合并回Develop，对开发人员要求较高,开发人员容易搞错导致Develop分支跟Master不一致
• 并行的feature分支太多时，代码冲突的可能性增加
• 当多个需求并行开发，如上特殊场景1情况，会造成分支污染

GitHub Flow

开发流程简述

1. 默认存在master分支，与生产保持一致（GitHub Flow模型默认分支的更新与产品的发布是一致）
2. 开发需求A，基于master检出分支A
3. A需求开发完成，提交合并到master的合并请求
4. 评审合并代码，处理合并请求（未处理前还可以持续提交）
5. 发布master 多个需求并行开发： 也与单个需求的开发一致，只是需要在master解决冲突，有可能多个需求分支合并到master后需要进行回归测试

特殊场景分析

场景2：当A分支开发完成后，合并到master，但此时由于各种原因未能发布到生产，此时会导致生产环境与master的代码不一致 解决方案：从master创建一个product分支，只有在master代码发布成功后才合并product 场景3：在多个需求并行开发的场景下，需要并行去测试这些功能分支，假设我以功能分支作为测试分支提供给测试团队，那可能需要具备多套测试环境，假设以master作为测试分支，会受到其他合并到master分支的污染

解决方案：控制质量，提高master准入标准

优缺点分析

优点：操作简单，可以持续发布

缺点：对于测试来说不那么友好

GitLab Flow

图1 图2

开发流程简述

1. GitLab Flow 开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展，如上面第一张图，最上游的MASTER作为开发分支，只有在开发分支完成，达到提交下一阶段的准入条件才能合并到PRE-PRODUCTION
2. 项目持续发布，假设某一个迭代版本开始，从生产分支检出Dev分支，后续从上游DEV经过测试验收达到准入要求后向下游SIT、UAT、PRE-PRODUCTION合并，最后发布，合并到PRODUCTION
3. 项目版本发布，如上图2，从master检出版本分支，并更新小版本后，持续维护这些版本分支。

特殊场景分析

场景4 :假设某功能分支流转到中间节点比如说UAT，但此时某些需求代码临时决定不上了，可能会污染UAT的代码

解决方案：回滚此代码，尽量保持中游分支的整洁

优缺点分析

优点：

• 方案同时兼顾了“版本发布”、“持续发布”
• 能够对各环境版本有较好的区分，对测试团队支持较好 缺点：存在中游分支被污染的风险

基于GitLab Flow的研发工作流程图解

总结

Git分支管理策略方案，要根据团队特性尽量选择复杂度低的方案，例如：在并行需求较少，不需要基于版本发布的团队，可以选择GitHub FLow模型；对测试环境要求较强可以选择GitLab Flow模型；在大型团队，开发人员技术水平较高，控制非常严格的情况下，可以参考Git FLow。在方案确定的过程中，不要只是套用模型，而是在模型的基础上，根据团队特性制定更简单、高效、风险系数低的方案。 本文分析与总结了三种Git分支管理策略，希望对大家在选择与指定版本管理方案时有所启发。