摘要：聊一聊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分支拉取一个新分支，在这个新分支上进行代码提交；性能开发实现，开发者创立Pull Request（简称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。

GitLabFlow中的Merge Request是将一个分支合入到另一个分支的申请，通过Merge Request能够比照合入分支和被合入分支的差别，也能够做代码的Review。

华为云DevCloud也反对GitLabFlow的合并申请，以爱护骨干分支不收烦扰。

1.设置爱护分支

仓库管理员在代码托管的“设置”中，抉择“爱护分支治理”，而后将Master（或Develop）分支设定为爱护分支，一般开发者不可向Master分支提交代码、也不容许合入代码，只有仓库管理员才能够向Master分支提交代码或合入代码。

2.创立合并申请

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

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

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

相干人员收到合并申请后，能够通过“文件变更”，比对文件前后的变动，确认无误后，可执行合入操作，如果有抵触可线上或线下解决抵触。

除了执行合并操作，还能够对代码进行评论打分，为Feature-Bill分支的合入提供倡议。

总结

分支策略不同，研发效率也不同，没有最好的分支策略，只有最适宜团队的分支策略，各分支策略的优缺点在下面曾经列出，大家能够依据团队状况，抉择适合的分支策略进行开发。

点击关注，第一工夫理解华为云陈腐技术~