『前端进阶』—— 代码管理方案之GitLab Flow

·  阅读 1716

前言

当你往高级前端进阶的过程中,避免不了要带领团队负责一个项目,此时你必定会遇到一个头疼的问题,代码如何进行管理。一般我们都使用Git来管理代码,业界中提供了几种Git工作流,每一种Git工作流就是一种代码管理方案,在对这几种Git工作流的流程熟悉后,才能给团队提供一种合适的代码管理方案。

本文将详细介绍其中一种Git工作流——GitLab Flow,希望对你有帮助,也欢迎在评论中讨论。

一、流程概念图

先上一张流程概念图,按图给你介绍GitLab Flow。

image.png

二、开发流程

GitLab Flow 的最大原则叫做"上游优先"(upsteam first),即只存在一个主分支master,它是所有其他分支的"上游"。只有上游分支采纳的代码变化,才能应用到其他分支。

故开发新功能前,要用master分支创建一个开发新功能的分支,分支的名称可以用功能名称来命名,这里先给这个分支命名为feature。

当功能开发完成后,用master分支去合并feature分支,合并完成后将feature分支删除。

三、测试流程

将master分支的代码部署到测试环境,测试出BUG,直接在master分支上修复,修复完成后部署到测试环境进行测试。

四、预发布流程

master分支的代码测试通过后,用master分支创建出一个分支,命名为pre-production。pre-production分支就是预发布分支,将其部署到预发布环境。

五、修复预发布环境BUG流程

预发布的代码出现BUG时,由于要遵循“上游优先”,不能直接在分支pre-production上修复BUG,得用pre-production分支创建出一个修复BUG的分支,分支的名字可以用BUG名称来命名,这里先给这个分支命名为fixbug。

将BUG修复后,用master分支合并fixbug分支,将master分支的代码部署到测试环境进行测试。

若没有通过测试,继续在fixbug分支上修复BUG,修复后再用master分支合并fixbug分支,再把master分支的代码部署到测试环境进行测试,直到BUG被修复。

BUG被修复后,用pre-production分支合并fixbug分支,然后将pre-production分支的代码部署到预发布环境进行测试,若测试通过则BUG修复完毕,删除fixbug分支,若测试不通过重复以上步骤。

六、正式环境发布流程

遵循“上游优先”原则,要用预发布pre-production分支创建出一个分支,命名为production。production分支就是正式分支,将其部署到正式环境,即完成正式环境发布流程。

七、修复正式环境BUG流程

遵循“上游优先”原则,得用production分支创建出一个修复BUG分支,分支的名字可以用BUG名称来命名,这里先给这个分支命名为fixbug。

在BUG修复后,在本地测试通过后,用master分支合并fixbug分支,将master分支的代码部署到测试环境进行测试。

若没有通过测试,继续在fixbug分支上修复BUG,再用master分支合并fixbug分支,将master分支的代码部署到测试环境进行测试,直到BUG被修复。

BUG修复后,要遵循“上游优先”原则,故要先把代码发到预发布环境进行测试,测试通过后才能发布到正式环境。

那么用pre-production分支合并fixbug分支。然后将pre-production分支的代码部署到预发布环境进行测试。

若测试通过,用production分支合并fixbug分支,然后部署到正式环境,删除fixbug分支。

若测试失败,重新回到fixbug分支修复BUG,继续走上面的流程,直到Bug被修复。

八、版本发布流程

GitHub Flow概念图2.png

在GitLab Flow 中版本发布不是采用打tag的形式。而是要用master分支创建一个分支,分支的名字可以如上图那样命名,比如2-3-stable、2-4-stable等等,要注意此时的master分支上的代码是稳定。

若版本分支的代码出现BUG,还是要在master分支上修复BUG,BUG被修复且通过测试后,在版本分支上执行命令git cherry-pick commitId,其中commitId是master分支上BUG修复的提交commitId,将修复BUG的代码合并到版本分支上,再将代码部署到对应的环境。

分类:
前端
标签: