阅读 986

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

“这是我参与更文挑战的第9天,活动详情查看: 更文挑战

前言

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

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

一、流程概念图

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

GitHub Flow概念图.png

二、开发流程

在GitHub Flow中只有一条主干分支master,该分支的代码作为正式环境的代码,不能在上面直接开发新功能或者修改BUG,然后进行commit。

master分支只能合并其它的功能分支或修复Bug分支,然后进行commit。所以在开发一个新功能时,要用master分支创建一个开发新功能的分支,分支的名称可以用功能名称来命名,这里先给这个分支命名为feature。

如流程概念图中所述的:

create a branch 创建分支

在开发过程中,不断往feature分支上commit代码。

如流程概念图中所述的:

add commits 添加提交

三、测试流程

当新功能开发完成后,可以发起一个pull request请求,后续简称PR。

如流程概念图中所述的:

open a pull request 发起一个pull请求

当项目负责人收到这个pull请求后,会对新功能进行讨论和回顾是否采用该功能,同时对feature分支的代码进行审核。

如流程概念图中所述的:

discuss and review 讨论和回顾

当项目负责人同意新功能可以发布,且代码也通过审核了。但是在pull之前还是要进行测试。所以要把feature分支的代码部署到测试环境进行测试。

四、修复测试环境BUG流程

在测试环境中出现的BUG,直接在feature分支上修复,修复完成后再部署到测试环境进行测试。

五、发布正式环境流程

在 GitHub Flow 中master分支作为正式环境的代码所在分支,

当feature分支的代码测试通过后,用master分支去合并feature分支,然后把master分支的代码部署到正式环境去,并把feature分支删除。

如流程概念图中所述的:

merge and deploy 合并和部署

上面的流程概念图对合并和部署的先后顺序描述有些不清晰,下面提供一张更清晰的流程概念图。

GitHub Flow概念图1.png

六、修复正式环境的BUG流程

上面提到过,正式环境的代码在master分支上,但是不能在master分支上直接修改,故还是从master分支创建一个修复BUG分支,分支的名称可以用BUG名称或fixbug加上版本号来命名,这里先给这个分支命名为fixbug。

在修复完成后,发起PR,PR通过后,部署到测试环境进行测试,测试通过后,切回master分支,合并fixbug分支,再将master分支的代码部署到正式环境,最后把fixbug分支删除。

文章分类
前端
文章标签