目前软件研发行业基于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 只定义了一系列分支和它们的用途,为了有效的利用这个模型,我们需要根据分支管理模型来定义团队的开发流程,包括特性开发、版本发布和紧急问题修复的流程等,下面是简要的流程定义:
功能特性开发
-
功能规划:从develop分支创建新的feature分支。
-
功能开发:在feature分支上进行开发。
-
代码审查和测试:确保代码质量符合标准。
-
合并回develop分支:完成测试后通过Pull Request或Merge Request。
功能特性发布
-
准备发布:从develop分支创建release分支。
-
发布前的测试和审查。
-
合并到master分支,并打上版本标签。
-
发布软件:从master分支发布新版本。
线上问题处理
-
从master分支创建hotfix分支。
-
修复问题并进行彻底测试。
-
合并hotfix分支到master和develop。
适用场景
-
复杂项目管理:适合功能丰富、团队规模较大或有规律发布需求的项目。
-
版本控制和发布管理:适合需要维护多个版本并有明确发布周期的软件项目。
前提和约束
-
每个生产版本都是基于以前的版本建立的。
-
新老版本之间可以存在并行期,但新版本上线后,旧版本只做功能修复。
最佳实践
要想更好的使用Git Flow,以下规范建议在团队内达成共识并予以遵循:
-
保持develop分支最新:develop分支作为所有开发活动的基础,需要保持最新状态。
-
为每个项目创建单独的feature分支:每个并行项目或功能都在自己的feature分支上进行开发。
-
定期合并develop到feature分支:为了避免合并冲突和确保一致性,定期将develop分支的更改合并到各个feature分支。
-
协调发布计划:在多个功能即将完成时,协调合并到develop分支的时间,以及随后的release分支创建和版本发布。
-
管理依赖和冲突:敏捷小组内,需要采取手段明确跟踪不同feature分支之间的依赖关系以决定合入顺序,后合入者解决冲突应该是一个团队内的共识,在后合入者不具备合并冲突并进行回归测试能力的情况下,高阶人员需要介入并予以支持