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

本文主要是介绍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）：该分支主要用于储存稳定版发布版本的代码，这是一个永不删除的分支，只会接受由 Release 或 Hotfix 分支合并的代码。同时，当 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 工作流过程如下：

首先，在项目的开发阶段，我们需要创建一个空的 Git 仓库，并初始化为一个新的项目；从空仓库创建一个 Main 主分支，用于存储稳定版本的代码，部署生产环境：
然后，基于 Main 主分支创建一个 Develop 开发分支，后续所有的开发工作都将在这个分支上进行：
根据团队的需求，为开发人员分配两个开发任务：
- 用户登录：用于允许用户在网站进行登录。此功能将作为 1.0 版本的一部分上线。
- 在线支付：用于在网站中实现在线支付功能。此功能将作为 2.0 版本的一部分上线。
明确功能后，基于 Develop 开发分支创建对应的 Feature 功能分支：
当用户登录功能在 Feature 功能分支上开发完成后，将 Feature 功能分支合并到 Develop 开发分支：
1.0 版本所需的用户登录功能开发完毕，此时 1.0 版本的功能为可发布状态，我们可以从 Develop 开发分支创建一个新的 Release 发布分支。在该分支上进行最终测试和缺陷修复：
在完成测试和修复后，将 Release 发布分支合并回 Main 主分支和 Develop 开发分支。同时，在 Main 主分支上打上标签Tag，以便追踪版本：
如果在生产环境中发现了紧急问题，可以直接从 Main 主分支上创建一个 Hotfix 补丁分支，并进行修复：
当问题成功解决后，将 Hotfix 补丁分支同步回 Main 主分支和 Develop 开发分支，以确保修复过的错误能在当前和未来的版本中得以修复。同时，在 Main 主分支上打上新的标签Tag：
此时，在线支付功能开发完毕，将 Feature 功能分支合并回 Develop 开发分支：
创建 Realse 发布分支准备发布 2.0 版本：
合并 Main 主分支，为 Main 主分支打上标签Tag 2.0.0，同时同步 Develop 开发分支:
团队成员根据需要继续创建新的功能分支、发布分支和补丁分支，推进项目的开发和维护工作。