Gitflow:一种依据 Git 构建的分支管理工作流程模式

2024-02-25 14:20

本文主要是介绍Gitflow:一种依据 Git 构建的分支管理工作流程模式,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

文章目录

    • 前言
    • Gitflow 背景
    • Gitflow 中的分支模型
    • Gitflow 的版本号管理
    • 简单模拟 Gitflow 工作流

前言

Gitflow 工作流是一种版本控制流程,主要适用于较大规模的团队。这个流程在团队中进行合作时可以避免冲突,并能快速地完成项目,因此在很多软件开发团队中都被广泛应用。通过使用 Gitflow 工作流,我们可以更好地管理代码的修改、版本的发布和协作,从而提高软件开发的效率和质量。在本篇文章中,我们将模拟一次典型的 Gitflow 工作流流程,让大家更好地理解这个工作流的工作流程和要点。

Gitflow 背景

“Gitflow 工作流程模型”的理念源自 Vincent Driessen(文森特·德里森)的深度研究与实践经验。在参与团队项目开发时,引入了 Gitflow 开发模型,之后又于2010年1月5日在一篇博客《A successful Git branching model》中详细阐述了该模型的理论基础及具体执行方式,并通过图表和实例进行解释,使读者能够更清晰、直观地理解并应用该模型。

这篇博客文章在软件开发领域引起了极大反响,被广泛传播和引用,为开发人员提供了一套结构严谨且可扩展的分支管理策略,从而提高工作效率和代码质量。如今,它已经成为使用 Git 进行团队协作和版本控制的开发者首要参照模型。

博客中的工作模型图如下:

3-01

Gitflow 中的分支模型

在 Gitflow 工作流程中,依据分支的寿命周期,我们可以将它们划分为长期分支短期分支

长期分支主要用于综合及管理诸多短期分支的代码,以此确保代码库的整体框架和稳定性,同时协助团队更加高效地管理和追踪各分支的进展及状态。通常,长期分支主要包括主分支(Main)和开发分支(Develop)这两部分:

  • 主分支(Main):该分支主要用于储存稳定版发布版本的代码,这是一个永不删除的分支,只会接受由 ReleaseHotfix 分支合并的代码。同时,当 Release 分支和 Hotfix分支被合并回 Main 分支后,我们会添加一个标签,以标记该版本的发布日期及版本序号等重要信息。过为每个版本打上标签,可以轻松地跟踪和回滚到特定的版本。
  • 开发分支(Develop):开发分支基于主分支建立。该分支包含了当前正进行的所有功能开发和错误修复工作,这也是一个持久性的分支。Develop 分支一般会接受来自 Feature 分支、 Release 分支和 Hotfix 分支的代码合并。

至于短期分支,主要是在项目开发历程中用于临时任务的分支,其生命周期相对较短,如:

  • 功能分支(Feature):功能分支主要用于开发新功能的开发。是从 Develop 分支创建,每个新功能都应在一个单独的 Feature 分支上进行开发,一旦功能开发完毕并通过测试,功能分支便会被合并回 Develop 分支。

  • 补丁分支(Hotfix):补丁分支则主要用于修复线上问题的分支。若在主分支 Main 上发现问题需要修复,那么我们会从 Main 分支上创建一个 Hotfix 分支进行修复,修复完成后,Hotfix 分支将被合并回 Main 分支和 Develop 分支,以保障修复过的错误能在当前和未来的版本中得以修正。

  • 发布分支(Release):发布分支用于准备发布一个稳定版的代码,在 Release 分支上进行最后的测试和修复,以确保代码质量和稳定性。一旦 Release 分支准备好发布,它将被合并回 Develop 分支和 Main 分支,以便在发布稳定版时使用。

Gitflow 的版本号管理

版本号的目的是提供一种明确和一致的方式来标识软件版本,使开发者和用户可以更清晰地了解版本的变化和影响,有助于管理依赖关系和追踪版本的演进。

目前常见的版本号格式定义是语义化版本规范,即所谓的"语义化版本控制(Semantic Versioning)",也叫作"SemVer"标准。它是一种用于标识和管理软件版本的规范,被广泛应用于软件开发。"SemVer"详细地界定了版本号的格式、具体所代表的含义以及整体更新原则,其根本宗旨就是为了让所有人都能以一致、确定的方式去描述和评估每次软件变动所带来的影响大小。

按照语义化版本控制的规范,一个版本号由三个部分组成:主版本号、次版本号和修订号,形式为 MAJOR.MINOR.PATCH ,每个部分都是非负整数,起始值为 0:

  • 主版本号(MAJOR 「大版本」):当进行不兼容的 API 变动或重大改进时增加。如果新版本与旧版本不兼容,用户可能需要修改代码才能适配新版本。
  • 次版本号(MINOR 「小版本」):当添加功能或进行向后兼容的改进时增加。新功能的引入不会破坏现有的 API,但用户可以利用新功能进行开发。
  • 修订号(PATCH 「修补版本」):用于修复 Bug 或进行其他小的改动,不会引入新的功能或破坏现有的 API。

此外,语义化版本控制还支持在版本号后面添加预发布标识和构建号。

  • 预发布标识(Pre-release):用于标识测试阶段的预发布版本,例如 alpha、beta、rc 等。预发布版本在正式发布之前进行测试和反馈。
  • 构建号(Build Metadata):用于标识每个构建的唯一编号,通常用于区分不同构建的细微差异。

例如对于版本号 v1.0.0,它代表着首个正式版本的发布。在这个版本中,可以期待有稳定的功能和已经修复的错误,但不会有任何新的重大功能引入。这个版本标记着软件的第一个里程碑,可以作为后续版本的基础。

注:版本号的具体规则和含义可能因团队或项目而异。因此在实际使用中,可以根据项目的需求和团队的约定来解释和定义版本号的含义。

简单模拟 Gitflow 工作流

假设我们有一个新的项目,需要使用 Gitflow 工作流进行代码管理和协作开发,Gitflow 工作流过程如下:

  1. 首先,在项目的开发阶段,我们需要创建一个空的 Git 仓库,并初始化为一个新的项目;从空仓库创建一个 Main 主分支,用于存储稳定版本的代码,部署生产环境:

    无标题-2024-01-09-2029

  2. 然后,基于 Main 主分支创建一个 Develop 开发分支,后续所有的开发工作都将在这个分支上进行:

    无标题-2024-01-09-2029

  3. 根据团队的需求,为开发人员分配两个开发任务:

    • 用户登录:用于允许用户在网站进行登录。此功能将作为 1.0 版本的一部分上线。
    • 在线支付:用于在网站中实现在线支付功能。此功能将作为 2.0 版本的一部分上线。

    明确功能后,基于 Develop 开发分支创建对应的 Feature 功能分支:

    无标题-2024-01-09-2029

  4. 当用户登录功能在 Feature 功能分支上开发完成后,将 Feature 功能分支合并到 Develop 开发分支:

    无标题-2024-01-09-2029

  5. 1.0 版本所需的用户登录功能开发完毕,此时 1.0 版本的功能为可发布状态,我们可以从 Develop 开发分支创建一个新的 Release 发布分支。在该分支上进行最终测试和缺陷修复:

    无标题-2024-01-09-2029

  6. 在完成测试和修复后,将 Release 发布分支合并回 Main 主分支和 Develop 开发分支。同时,在 Main 主分支上打上标签Tag,以便追踪版本:

    无标题-2024-01-09-2029

  7. 如果在生产环境中发现了紧急问题,可以直接从 Main 主分支上创建一个 Hotfix 补丁分支,并进行修复:

    无标题-2024-01-09-2029

  8. 当问题成功解决后,将 Hotfix 补丁分支同步回 Main 主分支和 Develop 开发分支,以确保修复过的错误能在当前和未来的版本中得以修复。同时,在 Main 主分支上打上新的标签Tag

    无标题-2024-01-09-2029

  9. 此时,在线支付功能开发完毕,将 Feature 功能分支合并回 Develop 开发分支:

    无标题-2024-01-09-2029

  10. 创建 Realse 发布分支准备发布 2.0 版本:

    无标题-2024-01-09-2029

  11. 合并 Main 主分支,为 Main 主分支打上标签Tag 2.0.0,同时同步 Develop 开发分支:

    无标题-2024-01-09-2029

  12. 团队成员根据需要继续创建新的功能分支、发布分支和补丁分支,推进项目的开发和维护工作。

这篇关于Gitflow:一种依据 Git 构建的分支管理工作流程模式的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/745748

相关文章

Security OAuth2 单点登录流程

单点登录(英语:Single sign-on,缩写为 SSO),又译为单一签入,一种对于许多相互关连,但是又是各自独立的软件系统,提供访问控制的属性。当拥有这项属性时,当用户登录时,就可以获取所有系统的访问权限,不用对每个单一系统都逐一登录。这项功能通常是以轻型目录访问协议(LDAP)来实现,在服务器上会将用户信息存储到LDAP数据库中。相同的,单一注销(single sign-off)就是指

Spring Security基于数据库验证流程详解

Spring Security 校验流程图 相关解释说明(认真看哦) AbstractAuthenticationProcessingFilter 抽象类 /*** 调用 #requiresAuthentication(HttpServletRequest, HttpServletResponse) 决定是否需要进行验证操作。* 如果需要验证,则会调用 #attemptAuthentica

嵌入式QT开发:构建高效智能的嵌入式系统

摘要: 本文深入探讨了嵌入式 QT 相关的各个方面。从 QT 框架的基础架构和核心概念出发,详细阐述了其在嵌入式环境中的优势与特点。文中分析了嵌入式 QT 的开发环境搭建过程,包括交叉编译工具链的配置等关键步骤。进一步探讨了嵌入式 QT 的界面设计与开发,涵盖了从基本控件的使用到复杂界面布局的构建。同时也深入研究了信号与槽机制在嵌入式系统中的应用,以及嵌入式 QT 与硬件设备的交互,包括输入输出设

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

Retrieval-based-Voice-Conversion-WebUI模型构建指南

一、模型介绍 Retrieval-based-Voice-Conversion-WebUI(简称 RVC)模型是一个基于 VITS(Variational Inference with adversarial learning for end-to-end Text-to-Speech)的简单易用的语音转换框架。 具有以下特点 简单易用:RVC 模型通过简单易用的网页界面,使得用户无需深入了

git使用的说明总结

Git使用说明 下载安装(下载地址) macOS: Git - Downloading macOS Windows: Git - Downloading Windows Linux/Unix: Git (git-scm.com) 创建新仓库 本地创建新仓库:创建新文件夹,进入文件夹目录,执行指令 git init ,用以创建新的git 克隆仓库 执行指令用以创建一个本地仓库的

maven 编译构建可以执行的jar包

💝💝💝欢迎莅临我的博客,很高兴能够在这里和您见面!希望您在这里可以感受到一份轻松愉快的氛围,不仅可以获得有趣的内容和知识,也可以畅所欲言、分享您的想法和见解。 推荐:「stormsha的主页」👈,「stormsha的知识库」👈持续学习,不断总结,共同进步,为了踏实,做好当下事儿~ 专栏导航 Python系列: Python面试题合集,剑指大厂Git系列: Git操作技巧GO

嵌入式Openharmony系统构建与启动详解

大家好,今天主要给大家分享一下,如何构建Openharmony子系统以及系统的启动过程分解。 第一:OpenHarmony系统构建      首先熟悉一下,构建系统是一种自动化处理工具的集合,通过将源代码文件进行一系列处理,最终生成和用户可以使用的目标文件。这里的目标文件包括静态链接库文件、动态链接库文件、可执行文件、脚本文件、配置文件等。      我们在编写hellowor

git ssh key相关

step1、进入.ssh文件夹   (windows下 下载git客户端)   cd ~/.ssh(windows mkdir ~/.ssh) step2、配置name和email git config --global user.name "你的名称"git config --global user.email "你的邮箱" step3、生成key ssh-keygen

模版方法模式template method

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/template-method 超类中定义了一个算法的框架, 允许子类在不修改结构的情况下重写算法的特定步骤。 上层接口有默认实现的方法和子类需要自己实现的方法