文章目录
- 前言
- Gitflow 背景
- Gitflow 中的分支模型
- Gitflow 的版本号管理
- 简单模拟 Gitflow 工作流
前言
Gitflow 工作流是一种版本控制流程，主要适用于较大规模的团队。这个流程在团队中进行合作时可以避免冲突，并能快速地完成项目，因此在很多软件开发团队中都被广泛应用。通过使用 Gitflow 工作流，我们可以更好地管理代码的修改、版本的发布和协作，从而提高软件开发的效率和质量。在本篇文章中，我们将模拟一次典型的 Gitflow 工作流流程，让大家更好地理解这个工作流的工作流程和要点。
Gitflow 背景
“Gitflow 工作流程模型”的理念源自 Vincent Driessen（文森特·德里森）的深度研究与实践经验。在参与团队项目开发时，引入了 Gitflow 开发模型，之后又于2010年1月5日在一篇博客《A successful Git branching model》中详细阐述了该模型的理论基础及具体执行方式，并通过图表和实例进行解释，使读者能够更清晰、直观地理解并应用该模型。
这篇博客文章在软件开发领域引起了极大反响，被广泛传播和引用，为开发人员提供了一套结构严谨且可扩展的分支管理策略，从而提高工作效率和代码质量。如今，它已经成为使用 Git 进行团队协作和版本控制的开发者首要参照模型。
博客中的工作模型图如下：
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开发分支:
-
团队成员根据需要继续创建新的功能分支、发布分支和补丁分支，推进项目的开发和维护工作。
