“这是我参与更文挑战的第9天,活动详情查看: 更文挑战”
前言
当你往高级前端进阶的过程中,避免不了要带领团队负责一个项目,此时你必定会遇到一个头疼的问题,代码如何进行管理。一般我们都使用Git来管理代码,业界中提供了几种Git工作流,每一种Git工作流就是一种代码管理方案,在对这几种Git工作流的流程熟悉后,才能给团队提供一种合适的代码管理方案。
本文将详细介绍其中一种Git工作流——GitHub Flow,希望对你有帮助,也欢迎在评论中讨论。
一、流程概念图
先上一张流程概念图,按图给你介绍GitHub Flow。
二、开发流程
在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 合并和部署
上面的流程概念图对合并和部署的先后顺序描述有些不清晰,下面提供一张更清晰的流程概念图。
六、修复正式环境的BUG流程
上面提到过,正式环境的代码在分支master上,但是不能在分支master上直接修改,故还是从分支master创建一个修复BUG分支,分支的名称可以用BUG名称或fixbug加上版本号来命名,这里先给这个分支命名为fixbug。
在修复完成后,发起PR,PR通过后,部署到测试环境,测试通过后,切回分支master,合并分支fixbug,再将分支master的代码部署到正式环境,最后把分支fixbug删除。