『前端进阶』—— 代码管理方案之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删除。

© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享