前言
版本控制系统是指对软件开发过程中程序代码、配置文件、文档等发生的变更进行管理的系统,它可以帮助团队更好的沟通协作,从而更好的进行交付,常见的版本控制系统分为集中式版本控制系统(如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分支的合入提供建议。
总结
分支策略不同,研发效率也不同,没有最好的分支策略,只有最适合团队的分支策略,各分支策略的优缺点在上面已经列出,大家可以根据团队情况,选择合适的分支策略进行开发。
本文分享自华为云社区《Git工作流中常见的三种分支策略:GitFlow、GitHubFlow以及GitLabFlow》,原文作者:敏捷的小智。