史上最全分支管理模型总结（GitFlow）

目前软件研发行业基于Git代码库的分支管理有Git Flow、GitHub Flow和GitLab Flow三种通用流程模型。其中，Git Flow是在Git诞生后不久提出的，而GitHub Flow和GitLab Flow则分别是这两个世界上最大的代码托管平台自身所支持的流程模型，二者都倡导小规模的频繁交付。

这段时间针对这三种通用流程模型进行了一次相对系统的分析，并对其进行了优、劣势对比和适用场景分析，整理出来分享给大家。

Git Flow是由 Vincent Driessen（文森特·德里森）在2010年提出的一种基于Git的工作流程。Vincent在他的博客文章《A successful Git branching model》中提出了Git Flow，提供了一种可靠的分支管理策略。

分支定义

• 主分支 (Master)

  • 功能：存放可发布、部署的稳定版本代码，用于生产环境的发布。

  • 生命周期：常驻。

  • 质量要求：高，通过严格的测试和代码审查。

• 开发分支 (Develop)

  • 功能：开发的主干，用于整合各个特性分支。

  • 生命周期：常驻。

• 特性分支 (Feature/xxx)

  • 功能：用于开发新特性或功能。

  • 生命周期：短期，从Develop分支创建，合回Develop分支。

• 发布分支 (Release/xxx)

  • 功能：准备新版本的发布。

  • 生命周期：短期，从Develop分支创建，合并到Master。

• 热修复分支 (Hotfix/xxx)

  • 功能：修复生产版本中的紧急问题。

  • 生命周期：短期，从Master分支创建，合并回Master和Develop。

流程模型

Git Flow 只定义了一系列分支和它们的用途，为了有效的利用这个模型，我们需要根据分支管理模型来定义团队的开发流程，包括特性开发、版本发布和紧急问题修复的流程等，下面是简要的流程定义：

功能特性开发

1. 功能规划：从develop分支创建新的feature分支。

2. 功能开发：在feature分支上进行开发。

3. 代码审查和测试：确保代码质量符合标准。

4. 合并回develop分支：完成测试后通过Pull Request或Merge Request。

功能特性发布

1. 准备发布：从develop分支创建release分支。

2. 发布前的测试和审查。

3. 合并到master分支，并打上版本标签。

4. 发布软件：从master分支发布新版本。

线上问题处理

1. 从master分支创建hotfix分支。

2. 修复问题并进行彻底测试。

3. 合并hotfix分支到master和develop。

适用场景

• 复杂项目管理：适合功能丰富、团队规模较大或有规律发布需求的项目。

• 版本控制和发布管理：适合需要维护多个版本并有明确发布周期的软件项目。

前提和约束

1. 每个生产版本都是基于以前的版本建立的。

2. 新老版本之间可以存在并行期，但新版本上线后，旧版本只做功能修复。

最佳实践

要想更好的使用Git Flow，以下规范建议在团队内达成共识并予以遵循：

• 保持develop分支最新：develop分支作为所有开发活动的基础，需要保持最新状态。

• 为每个项目创建单独的feature分支：每个并行项目或功能都在自己的feature分支上进行开发。

• 定期合并develop到feature分支：为了避免合并冲突和确保一致性，定期将develop分支的更改合并到各个feature分支。

• 协调发布计划：在多个功能即将完成时，协调合并到develop分支的时间，以及随后的release分支创建和版本发布。

• 管理依赖和冲突：敏捷小组内，需要采取手段明确跟踪不同feature分支之间的依赖关系以决定合入顺序，后合入者解决冲突应该是一个团队内的共识，在后合入者不具备合并冲突并进行回归测试能力的情况下，高阶人员需要介入并予以支持