likes
comments
collection
share

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

作者站长头像
站长
· 阅读数 6

​​​​​​摘要: 聊一聊 Git 中的工作流——分支策略。

前言

版本控制系统是指对软件开发过程中程序代码、配置文件、文档等发生的变更进行管理的系统,它可以帮助团队更好的沟通协作,从而更好的进行交付,常见的版本控制系统分为集中式版本控制系统(如 SVN)和分布式版本控制系统(如 Git)。

之前拜访一家企业,企业内的开发团队使用 Git 管理日常开发工作,在开发过程中遇到一个问题:分支策略使用很混乱——最初开发团队从主干分支拉出一条特性分支,但新功能完成后,该特性分支没有合入主干分支,而是作为下次开发的主干分支,重新拉出一条新的特性分支,导致主干分支一直形同虚设,团队没有一条稳定的代码分支。

这个问题很大程度上源于团队对分支策略的不了解,本文就简单聊一聊 Git 中的工作流——分支策略。

常见的分支策略

上文中提到的团队使用分支策略很混乱,这种分支策略也并不是主流的,使用主流的分支策略则会避免以上问题。

常见的分支策略有以下三种:GitFlow、GitHubFlow 以及 GitLabFlow。

Git Flow

GitFlow 是这三种分支策略中最早出现的。

GitFlow 通常包含五种类型的分支:Master 分支、Develop 分支、Feature 分支、Release 分支以及 Hotfix 分支。

  • Master 分支:主干分支,也是正式发布版本的分支,其包含可以部署到生产环境中的代码,通常情况下只允许其他分支将代码合入,不允许向 Master 分支直接提交代码(对应生产环境)。

  • Develop 分支:开发分支,用来集成测试最新合入的开发成果,包含要发布到下一个 Release 的代码(对应开发环境)。

  • Feature 分支:特性分支,通常从 Develop 分支拉出,每个新特性的开发对应一个特性分支,用于开发人员提交代码并进行自测。自测完成后,会将 Feature 分支的代码合并至 Develop 分支,进入下一个 Release。

  • Release 分支:发布分支,发布新版本时,基于 Develop 分支创建,发布完成后,合并到 Master 和 Develop 分支(对应集成测试环境)。

  • Hot fix 分支:热修复分支,生产环境发现新 Bug 时创建的临时分支,问题验证通过后,合并到 Master 和 Develop 分支。

通常开发过程中新特性的开发过程如下:

从 Develop 分支拉取一条 Feature 分支,开发团队在 Feature 分支上进行新功能开发;开发完成后,将 Feature 分支合入到 Develop 分支,并进行开发环境的验证;开发环境验证完成,从 Develop 分支拉取一条 Release 分支,到测试环境进行 SIT/UAT 测试;测试无问题后,可将 Develop 分支合入 Master 分支,待发版时,直接将 Master 分支代码部署到生产环境。

可参考下图:

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

GitFlow 的优点是每个分支都有明确的定义,严格按照 GitFlow 管理项目代码的话,很难出现代码混乱;其缺点是:如果特性分支过多的话很容易造成代码冲突,从而提高了合入的成本;由于每次提交都涉及多个分支,所以 GitFlow 也太不适合提交频率较高的项目。

使用华为云 DevCloud 实现 Git Flow

1.创建分支

华为云 DevCloud 的代码托管功能支持端到端的 GitFlow,我们在代码仓库中可新建分支,如图,目前已有主要分支:Master 分支和 Develop 分支,和两个特性分支:Feature-Bill 和 Feature-Score 分支。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

2.为分支创建流水线

流水线功能需要在华为云 DevCloud 的流水线功能中进行配置,基于“Feature-Bill”分支新建一条流水线。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

在流水线中配置构建、部署任务,以便于对 Feature-Bill 分支代码的构建、部署进行验证(构建、部署等任务需要提前在对应模块下创建)。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

3.Feature 提交代码并验证

Feature-Bill 分支开发完成后,提交代码即可触发流水线进行验证。

4.代码合入 Develop 分支进行验证

同理还需要为 Develop 分支创建一条流水线,当 Feature-Bill 分支通过 merge 命令合入到 Develop 分支之后,由于 Develop 分支的代码发生了变化,也会触发流水线进行验证。

Develop 分支验证没问题后,团队可以拉取 Release 分支,创建并启动 Release 分支的流水线进行测试环境验证。若发现缺陷,可直接在 Release 分支进行修改、验证。当测试环境验证通过后,将代码合入 Master 分支,创建并启动 Master 流水线进行生产环境升级与验证。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

GitHubFlow

GitHubFlow 看名字也知道和 GitHub 有关,它来源于 GitHub 团队的工作实践。当代码托管在 GitHub 上时,则需要使用 GitHubFlow。相比 GitFlow 而言,GitHubFlow 没有那么多分支。

GitHubFlow 通常只有一个 Master 分支是固定的,而且 GitHubFlow 中的 Master 分支通常是受保护的,只有特定权限的人才可以向 Master 分支合入代码。

在 GitHubFlow 中,新功能开发或修复 Bug 需要从 Master 分支拉取一个新分支,在这个新分支上进行代码提交;功能开发完成,开发者创建 PullRequest(简称 PR),通知源仓库开发者进行代码修改 review,确认无误后,将由源仓库开发人员将代码合入 Master 分支。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

很多人可能会问,提交代码通常是 commit 或者 push,拉取代码才是 pull,为什么 GitHubFlow 中提交代码提出的是“Pull Request”。因为在 GitHubFlow 中,PR 是通知其他人员到你的代码库去拉取代码至本地,然后由他们进行最终的提交,所以用“pull”而非“push”。

GitHubFlow 优点是相对于 GitFlow 来说比较简单,其缺点是因为只有一条 Master 分支,万一代码合入后,由于某些因素 Master 分支不能立刻发布,就会导致最终发布的版本和计划不同。

GitLabFlow

GitLabFlow 出现的最晚,GitLabFlow 是开源工具 GitLab 推荐的做法。

GitLabFlow 支持 GitFlow 的分支策略,也支持 GitHubFlow 的“Pull Request”(在 GitLabFlow 中被称为“Merge Request”)。

相比于 GitHubFlow,GitLabFlow 增加了对预生产环境和生产环境的管理,即 Master 分支对应为开发环境的分支,预生产和生产环境由其他分支(如 Pre-Production、Production)进行管理。在这种情况下,Master 分支是 Pre-Production 分支的上游,Pre-Production 是 Production 分支的上游;GitLabFlow 规定代码必须从上游向下游发展,即新功能或修复 Bug 时,特性分支的代码测试无误后,必须先合入 Master 分支,然后才能由 Master 分支向 Pre-Production 环境合入,最后由 Pre-Production 合入到 Production。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

GitLabFlow 中的 MergeRequest 是将一个分支合入到另一个分支的请求,通过 MergeRequest 可以对比合入分支和被合入分支的差异,也可以做代码的 Review。

华为云 DevCloud 也支持 GitLabFlow 的合并请求,以保护主干分支不收干扰。

1.设置保护分支

仓库管理员在代码托管的“设置”中,选择“保护分支管理”,然后将 Master(或 Develop)分支设定为保护分支,普通开发者不可向 Master 分支提交代码、也不允许合入代码,只有仓库管理员才可以向 Master 分支提交代码或合入代码。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

2.创建合并请求

在代码仓库的“合并请求”中,创建一条合并请求,请求将 Feature-Bill 分支合入 develop 分支。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

并指定评审人员和执行合入操作的人员。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

3.Review 代码并通过合并请求

相关人员收到合并请求后,可以通过“文件变更”,比对文件前后的变化,确认无误后,可执行合入操作,如果有冲突可线上或线下解决冲突。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

除了执行合并操作,还可以对代码进行评论打分,为 Feature-Bill 分支的合入提供建议。

Git 工作流中常见的三种分支策略:GitFlow、GitHubFlow 和 GitLabFlow

总结

分支策略不同,研发效率也不同,没有最好的分支策略,只有最适合团队的分支策略,各分支策略的优缺点在上面已经列出,大家可以根据团队情况,选择合适的分支策略进行开发。

转载自:https://juejin.cn/post/6984995032369463326
评论
请登录