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

关注

发布于: 2021 年 07 月 15 日

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

本文分享自华为云社区《Git工作流中常见的三种分支策略：GitFlow、GitHubFlow以及GitLabFlow》，原文作者：敏捷的小智。

前言

版本控制系统是指对软件开发过程中程序代码、配置文件、文档等发生的变更进行管理的系统，它可以帮助团队更好的沟通协作，从而更好的进行交付，常见的版本控制系统分为集中式版本控制系统（如 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 分支代码部署到生产环境。

可参考下图：

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

使用华为云 DevCloud 实现 Git Flow

1.创建分支

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

2.为分支创建流水线

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

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

3.Feature 提交代码并验证

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

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

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

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

GitHubFlow

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

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

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

很多人可能会问，提交代码通常是 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。