当前位置：首页 > news >正文

Git（三） Git 分支工作流管理模型探究与实践

news 来源：原创 2025/6/16 11:20:19

一. Git Flow 分支工作流

1. 分支类型

2. 工作模式

3. 特点与适用场景

4. 总结与思考

二. 基于版本驱动的有主分支工作流

1. 分支类型

2. 工作模式

三. 基于版本驱动的无主分支工作流

1. 分支管理模型

1.1 分支类型

1.2 工作模式

1.3 特点与适用场景

2. 分支开发流程

本文系统介绍了三种Git分支工作流模型：1. GitFlow工作流：结构化分支模型，包含主分支(master)、开发分支(develop)及多种辅助分支，适用于多版本维护的项目；2. 有主分支工作流：基于master主分支与develop开发分支的简化版本，适合常规版本发布需求；3. 无主分支工作流：完全由版本迭代驱动的简化模型，仅使用develop分支跟随版本轮转，适合周期性迭代项目。

一. Git Flow 分支工作流

A successful Git branching model：A successful Git branching model » nvie.com

图 1.1 Git Flow 工作流

图 1.2 Breaking Change 历史版本维护

Git Flow 是一种严格结构化、围绕版本发布为核心的 Git 工作流模型，需要注意这与持续发布的项目模式是不同的，其目标是基于时间线不断产出新版本来驱动系统演进。该分支管理模型的核心在于使用不同功能、生命周期明确的分支来严格分离开发的不同阶段，支持多版本并行、历史版本维护等复杂场景，衍生出多种简化版本的工作流模型。

1. 分支类型

Git Flow 工作流中的分支主要由核心分支和辅助分支两种类型组成，每种分支的角色与职责介绍如下：

核心分支：核心分支都属于长期分支，应在项目进行阶段持续存在
- 主分支（master/main）：主分支上的每个节点都表示生产环境发布的稳定正式版本，并使用版本号Tag标记每个提交。主分支不允许直接进行代码修改，只能接受来自hotfix分支和release分支的合入提交；
- 开发分支（develop）：开发分支也称为集成分支，可以看作是主分支的超集（包含已发布功能、计划发布功能），用于进行持续开发和功能合并，当开发分支迭代达到发布条件时应及时创建版本发布分支release。开发分支只能接受来自feature分支、hotfix分支和release分支的合入提交；
- 支持分支（support）：支持分支用于在主分支发生破坏性版本提交（breaking change）时接替主分支的角色继续维护对应历史并行版本，该分支只能接受来自于feature分支的合入提交；
辅助分支：辅助分支都属于短期分支，可在分支使用完成后废弃
- 功能分支（feature）：功能分支是用于完成特定的功能或开发任务而从开发分支或支持分支临时创建的分支，该分支通常只存在于开发人员的本地仓库，除非该功能分支需要多人协同开发；
- 发布分支（release）：发布分支是在开发分支达到版本发布条件时（新功能积累完成或到达发布周期）为新版本预发布而创建的隔离分支，使得开发分支可以继续接受后续版本计划的功能提交。发布分支创建后通常将不再添加新功能，仅用于进行版本发布前的集成测试、缺陷修复和生成发布文档等，注意该分支在准备就绪后除了合并回主分支发布还必须合并回开发分支以同步变更；
- 补丁分支（hotfix）：补丁分支非常短暂，仅用于紧急修复生产环境中主分支上产生的线上问题或安全漏洞，该分支在修复完成后必须立即合并回主分支以及开发分支；

2. 工作模式

日常开发场景：develop -> feature -> develop -> release -> master/develop
历史维护场景：master -> support -> feature -> support
紧急修复场景：master -> hotfix -> master/develop
紧急需求场景：develop -> release -> master/develop

3. 特点与适用场景

图 1.3 Git Flow VS GitHub Flow

严格结构化管理：明确的多分支定义，工作流程结构化，能够清晰分离不同开发阶段，支持多开发活动并行进行。适用于大型团队与复杂项目的协作与管理，降低发布阻塞风险；
强版本控制：发布节点清晰可溯、版本历史明确，支持多个版本并行维护。适用于有明确版本发布计划、发布周期较长或需要维护历史版本的项目；
复杂且不够灵活：复杂程度较高且发布周期较长，存在“合并地狱”问题，不适用于需要频繁发布和持续部署、或版本概念弱相关的项目及团队，这种场景可以考虑GitHub Flow或GitLab Flow工作模型；

4. 总结与思考

图1.4 By Vincent Driessen

这个模型是在2010年构思的，到现在已经10多年了，也就是Git本身诞生不久之后。在这10年里，Git Flow 在许多软件团队中变得非常流行，以至于人们开始将其视为某种标准，但不幸的是它也被视为教条或灵丹妙药。如果你的团队正在进行软件的持续交付，我建议采用更简单的工作流程（如GitHub Flow），而不是试图将Git Flow强行塞进你的团队。然而如果你正在构建明确版本化的软件，或者你需要同时支持软件的多个版本，那么Git Flow可能仍然适合你的团队。总之永远记住，灵丹妙药并不永远存在。

-- Vincent Driessen

二. 基于版本驱动的有主分支工作流

图2.1 Git 分支工作流

1. 分支类型

master分支：master主分支长期存在，其代码总是稳定可靠的，并可随时发布。注意不能在该分支上直接修改代码，所有具备上线条件的版本都需要合并到master分支；
develop分支：develop分支长期存在，该分支将从master主分支跟随版本创建，用于当前版本的开发使用。注意当版本具备上线条件时，需要合并回master分支以及后续版本的develop分支；
hotfix分支：hotfix分支短期存在，该分支将从master主分支创建，用于线上版本问题的紧急修复，注意fix完成后需合并回master分支、develop分支；

2. 工作模式

版本开发： 软件开发工程师根据版本从master主分支最新节点上创建版本开发分支develop，并在develop分支上完成当前版本所有功能需求的开发，当具备发布条件时需强制检测master主分支的代码改动并合入当前版本分支，推送版本转测；
问题修复：当需要紧急修复线上问题时，由开发工程师从master主分支节点上创建修复分支hotfix，并在修复完成后直接合入主分支，注意主分支master上的改动需合并到后续版本的develop分支以完成同步；

三. 基于版本驱动的无主分支工作流

图3.1 版本迭代计划示意图

假设系统的版本迭代基于四周版本迭代计划驱动：即以两周为一个完整的开发周期、以四周为一个完整的上线周期，在版本迭代周期中由开发版本、测试版本和上线版本三个版本串行轮转。开发人员在版本迭代周期中的职责包括：

开发版本：负责迭代功能与需求的设计、评审、实现与自测，保证基本功能逻辑能够覆盖大部分场景、核心流程不出问题（冒烟通过）；
测试版本：负责解决测试版本中产生的缺陷问题、以及体验与优化等问题，保证版本功能逻辑的完善、尽可能满足用户需求；
上线版本：负责上线版本巡检、以及线上问题的处理，保证线上用户的正常使用、避免产生客诉问题；

图3.2 Git 分支工作流

1. 分支类型

系统的云端分支类型只有develop开发分支，该分支始终跟随版本创建，当前版本develop分支将从上个版本develop分支的最新节点创建（一般为转测节点）并长期存在，用于承载当前版本的开发、转测、修复与上线发布等全生命周期的工作。

2. 工作模式

（1）分支创建：分支跟随版本从上个develop分支的最新节点创建，开发分支的命名通常由分支前缀和版本标识两部分组成并通过"_"下划线连接（如“分支前缀_版本标识”），具体包含正常迭代和紧急支持两种开发场景；

正常迭代版本：版本号使用偶数迭代。正常迭代版本是指按照版本迭代计划正常驱动的需求或版本，比如 dev_1.1.0、dev_1.1.2 ...
紧急支持版本：版本号使用奇数迭代。紧急支持版本是指在系统迭代计划三个版本串行轮转过程中紧急插入或需紧急上线的需求或问题，需单独转测或无法跟随任何正常迭代版本上线的特殊情况，由于该模式不维护历史版本也不支持多版本并行，因此针对紧急需求将启用奇数版本号，比如 dev_1.1.1、dev_1.1.3 ...

（2）开发与提交：开发人员基于当前版本创建的develop分支在本地checkout out检出并进行开发和提交（支持多人协同开发），当代码开发完成后需及时推送及合入远程develop分支，并手动解决提交过程中产生的代码冲突；

（3）转测与发布：当版本功能全部开发完成并自测通过、具备转测条件时，由开发人员在当前版本develop分支的最新节点上打Tag发布转测版本同步到测试人员，并在该develop分支上持续跟踪并修复缺陷问题直到转测过程完全通过，当版本具备上线条件时需要将该版本develop分支合并回后续版本的develop分支以保证代码同步（版本推送前需强制进行分支合并检查是否合并了之前分支的最新代码）；

图3.3 Git 分支开发流程