GitFlow Workflow 工作流理论模型

原创已于 2025-10-14 15:07:48 修改 · 1.1k 阅读

本内容遵循CC 4.0 BY-SA版权协议

于 2025-08-06 01:07:38 首次发布

摘要

本文主要分享Gitflow Workflow的工作流模型，分析其基于master develop featrue release hotfix的分支管理策略，工作过程中如何使用该工作流模型，促使团队有效沟通合作，共同完成一个复杂项目的开发工作。
在这里插入图片描述

前言

在使用 Git 进行版本控制时，有几种常见的工作流程被广泛采用。每种工作流程都有其适用场景和特点，下面介绍一些最常用的 Git 工作流程

序号	工作流	特点
1	Gitflow Workflow	结构清晰，适合大型团队和复频繁发布的复杂项目，但对于小型项目或快速迭代的项目来说可能过于复杂
2	GitHub Flow	一种更为轻量级的工作流，强调频繁集成和部署，特别适合于开源项目或小型团队，对于需要同时维护多个稳定版本的项目不太适用
3	GitLab Flow	是 GitHub Flow 的扩展，增加了对环境（如 staging, production）的支持，更适合企业级应用
4	Forking Workflow	非常适合开放源码社区，因为它允许任何人贡献代码而不影响原始仓库的安全性，对于内部团队协作来说，可能会增加不必要的复杂度
5	Feature Branch Workflow	强调所有功能开发都在独立的分支上进行，简单灵活，但没有明确的规则来处理发布和热修复，可能需要额外的流程定义

选取原则：应该按照当前团队的大小、项目的复杂度以及具体需求选择使用哪种工作流，只要能够帮助团队进行有效的沟通与协作，同时促进高质量软件的持续交付就可以。

GitFlow介绍

Gitflow Workflow是一种严格的git分支管理模型，由 Vincent Driessen 在 2010 年提出，专用于管理大型、复杂项目的结构化方法，尤其是需要频繁发布版本，适用于大型团队。
Gitflow Workflow的分支的概念如下：

分支	内容
Master	主分支，代表官方发布的代码库，包含的是经过测试的、稳定的版本程序，可直接编译、运行，该分支的只接受来自其他分支合并来的程序，不可直接修改
Develop	开发分支，其中包含下一个版本需要实现的新功能
Release	发布分支，由Develop完成新功能合并后，派生到该支线上，在该支线上进行软件测试与修复
Feature	新功能分支，基于Develop分支到该线，在此支线完成新功能开发，开发完后合并到Develop
Hotfix	修复分支，当Master有Bug需要处理时，分支到该线上，修复完成后合并到Master和Develop分支

注意：分支是一个严格但又廉价的事情，要严格按照其模型执行，且分支的成本很低，不要怕分支开的多

主分支 Master

在这里插入图片描述
Master上存放官方发布的正式版程序，是各个程序中最稳定的版本，该分支的代码是可以随时编译随时运行的。当一个新功能完成且测试稳定后，就要合并到该分支上，每一次合并更新都需要在该线上打对应的Tag版本号(如图步骤2 tag 0.1 1.0 1.1)，该分支长期存在。
Master上的代码是不允许任何人进行修改的，只能由其他分支经过多轮测试合格后，合并到该分支上，一般是从Hotfix、Release分支合并过来（如图步骤14 18）。

开发分支 Develop

在这里插入图片描述
该分支由Master派生而来（如图步骤1），Develop用于整合即将在下个版本中发布的所有新功能。将各Feature分支合并上来之前，需要保证待合并的各Feature的的完整性，确保合并上来后，Feature可以正常运行，当整合完成且整体状态稳定后，就会从此处创建一个Release分支（如图步骤1）。

功能分支 Feature

在这里插入图片描述
Feature分支派生自Develop（如图步骤4 5），分支一般命名为Featrure/XXX(功能名)，主要用于开发实现下一个版本或探索未来可能用的功能，要注意Feature不会一直存在，当功能开发完成后就要合并到Develop分支上（如图步骤8），或者功能开发的效果不好时直接终止（如图步骤10）。
该分支一般是存在与开发者本地电脑上，除非是多个人合作开发，才需要将分支程序传送到服务器上，且尽量按照次数多、颗粒小的原则进行代码上传，防止直接上传特别大的分支。
该分支只和Develop合并，不会和其他分支有交集，而且Feature下的各个子分支也只能派生自此父Feature分支（如图步骤6 7 9）。

发布分支 Release

在这里插入图片描述
发布分支命名：Release/1.1（Ver:1.1），由Develop派生而来（如图步骤11），专用于测试Develop上合并好的新功能，当Release测试没有问题后，需要合并到Develop和Master分支（如图步骤14 15）。Develop派生出Release后进入空档期，计划下一个版本需要实现的功能。在Release分支上主要的工作有：

将分支程序上传到服务器
测试工程师对分支程序进行测试
开发工程师对测试出来的问题进行修改（如图步骤13）
编写版本变更的说明文档
！绝对不会在此分支添加新功能，因为是测试和修复。

热修复分支 Hotfix

在这里插入图片描述
分支命名称：Hotfix/1.3.1(软件版本)，当Master上的代码出现问题需要维护时，由Master的有问题的tag版本处派生出该分支（如图步骤17），并在tag版本后面附上子版本，由专业的问题修复人员完成维护工作，即开发和修复可以并行。之所以专门开一个Hotfix分支去做，而不是合并到Develop中去做，主要是因为：

develop中可能存在新的未验证的Feature，将Feature的新功能和Bug一起测试、验证、修改，十分困难
当前tag版本的Master可能无法包含新Feature，用户可能也不需要
一般这种是需要紧急修复，Feature新功能肯定没有时间发布
Hotfix修复好Bug后，除了合并到Master（如图步骤18），也要合并到Develop中（如图步骤20），因为Develop中肯定也包含此Bug。