一、为什么要选择GitFlow管理方案
版本控制系统是指对软件开发过程中程序代码、配置文件、文档等发生的变更进行管理的系统,它可以帮助团队更好的沟通协作,从而更好的进行交付,常见的版本控制系统分为集中式版本控制系统(如SVN)和分布式版本控制系统(如Git)。
之前拜访一家企业,企业内的开发团队使用Git管理日常开发工作,在开发过程中遇到一个问题:分支策略使用很混乱——最初开发团队从主干分支拉出一条特性分支,但新功能完成后,该特性分支没有合入主干分支,而是作为下次开发的主干分支,重新拉出一条新的特性分支,导致主干分支一直形同虚设,团队没有一条稳定的代码分支。
这个问题很大程度上源于团队对分支策略的不了解。
二、常见的分支策略
上文中提到的团队使用分支策略很混乱,这种分支策略也并不是主流的,使用主流的分支策略则会避免以上问题。
常见的分支策略有以下三种:GitFlow、GitHubFlow以及GitLabFlow。
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 Flow详解
-
当我们新建git仓库之后,默认会创建一个主分支也就是master分支,由于master分支是用于发布生产环境,所有必须保证master上代码的稳定性,所以我们不能直接在master分支上修改提交。我们要基于master分支创建一个develop分支,develop分支用于保存开发好的相对稳定的功能,master分支和develop分支是仓库的常驻分支,一直会保留在仓库中
-
当新的开发任务来了之后,就要编写代码了,我们尽量不要在develop分支上写代码,要保证develop分支的相对稳定,所以这时我要就要基于develop 分支创建一个临时的开发分支,然后在开发分支上编写代码,等功能开发完之后我们再把开发分支合并到develop上
-
新功能合并到develop分支之后,我们想把新功能发布到生产环境,首先基于develop分支创建release分支,然后在release分支测试完成之后,把release分别合并到master分支和develop分支
-
release分支合并到master分支之后,在master分支上打标签用于发布:
-
我们把代码发布到了生产环境,用户在使用的时候给我们反馈了一个bug,这时我们需要基于master分支创建一个hotfix 分支,用于修复bug,bug修好之后,把hotfix 分支分别合并到master分支和develop分支
linux系统安装gitflow工具
apt-get install git-flow
工具命令
-
初始化 GitFlow:
-
git flow init
:在 Git 仓库中初始化 GitFlow 工作流程。这个命令会引导你设置主分支、开发分支、功能分支、发布分支和修复分支的命名约定。
-
-
开始新功能:
-
git flow feature start <feature-name>
:从开发分支创建一个新的功能分支,并切换到该分支开始开发新功能。 -
git flow feature finish <feature-name>
:完成当前功能分支的开发,将其合并回开发分支,并删除该功能分支。
-
-
发布版本:
-
git flow release start <version>
:从开发分支创建一个新的发布分支,用于准备发布新版本。可以在该分支上进行版本号的调整和最终的测试工作。 -
git flow release finish <version>
:完成发布分支的工作,包括版本号的调整、合并回开发分支和主分支,并打上版本标签。
-
-
修复 Bug:
-
git flow hotfix start <version>
:从主分支创建一个新的修复分支,用于解决紧急的 bug。通常用于生产环境的 bug 修复。 -
git flow hotfix finish <version>
:完成修复分支的工作,包括合并回主分支和开发分支,并打上修复版本的标签。
-
-
查看当前状态:
-
git flow feature
:查看当前所有的功能分支。 -
git flow release
:查看当前所有的发布分支。 -
git flow hotfix
:查看当前所有的修复分支。
-
三、测试用例
验证功能开发: 在 GitFlow 中,新功能通常会在一个独立的 feature 分支上进行开发。在开发过程中,测试用例被用来验证功能是否按照预期工作。测试用例可以覆盖功能的各种方面,包括正常使用情况和边缘情况。
确保集成质量: 当一个功能完成并准备合并到主分支时,测试用例可以确保该功能的质量和稳定性。通常会使用自动化测试来运行这些测试用例,以确保每次合并到主分支的代码都经过了验证。
防止回归问题: 测试用例也可以用来检测在开发新功能或修复 bug 时引入的回归问题。通过编写测试用例来模拟已知的 bug 或边界情况,可以在代码更改后自动运行这些测试,以确保新的更改不会导致已有功能的故障。
文档化功能: 测试用例也可以作为功能的文档,描述了功能应该如何工作以及预期的行为。这有助于团队成员了解功能的期望行为,并在开发和维护过程中提供参考。
对于如何编写测试用例,一般遵循以下几个步骤:
确定测试范围: 确定要测试的功能或代码段,并了解其预期行为。
编写测试用例: 根据功能或代码的预期行为编写测试用例。测试用例应该覆盖正常情况和可能的边缘情况。
运行测试: 运行测试用例来验证功能是否按照预期工作。可以手动运行测试,也可以使用自动化测试框架来自动运行测试。
修复问题: 如果测试用例失败,则表示代码存在问题。开发人员应该查找并修复问题,直到测试用例通过为止。文章来源:https://www.toymoban.com/news/detail-860904.html
持续集成: 将测试用例集成到持续集成/持续交付 (CI/CD) 流程中,确保每次代码更改都会自动运行测试用例,以及时发现和修复问题。文章来源地址https://www.toymoban.com/news/detail-860904.html
到了这里,关于GitFlow 分支管理方案及测试用例的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!