GitHub Flow和GitLab Flow有什么区别？

Avi*_*nar 29 git version-control github gitlab

最近我在GIT中找到了工作流的三个概念:GitFlow,GitHub Flow和GitLab Flow.我已经阅读了关于它的好文章(https://docs.gitlab.com/ee/workflow/gitlab_flow.html),但我不太了解GitLab Flow.也许是因为我不是母语人士:)

简单地说.

GitFlow(https://docs.gitlab.com/ee/workflow/gitdashflow.png).

我们有一个主分支作为生产分支.我们还有一个开发分支,每个开发人员都会合并他的功能.有时我们会创建一个发布分支来在生产中部署我们的功能.如果我们在发布分支中有错误,请修复它并将更改拉入开发分支.如果我们在生产中存在严重错误,请创建新的修补程序分支,修复错误并将分支与生产(主)合并并开发分支.

如果我们很少显示我们的工作成果,这种方法非常好.(也许每2周一次).

GitHub Flow(https://docs.gitlab.com/ee/workflow/github_flow.png).

我们有一个主分支作为生产分支.我们(作为开发人员)只能创建分支以添加新功能或修复错误并将其与生产(主)分支合并.听起来很简单.这种方法适用于极端编程,其中生产分支在一天内被多次部署.

GitLab流量(https://docs.gitlab.com/ee/workflow/production_branch.png,https://docs.gitlab.com/ee/workflow/environment_branches.png,https://docs.gitlab.com/ee /workflow/release_branches.png).

我见过新的术语,如预生产,生产,发布(稳定)分支和临时环境,预生产环境,生产环境.他们之间有什么关系？

我这样理解:如果我们需要添加新功能,我们从主分支部署预生产分支.完成功能后,我们从预生产分支部署生产分支.预生产分支是中间阶段.然后主分支从生产分支中提取所有更改.

如果我们想要查看每个单独的功能,那么这种方法很好.我们只是在分行结账我们需要和看看.

但是如果我们需要展示我们的工作,我们会尽可能晚地创建一个带有标签的发布分支.如果稍后我们修复master分支中的错误,我们需要将它们挑选到最后一个发布分支.最后,我们有一个带有标签的发布分支,可以帮助我们在不同版本之间移动.

我的视力是否正确？拉和樱桃挑选有什么区别？

Ale*_*ich 22

GitLab Flow也建议使用master和feature分支.功能完成后,我们将其合并回master分支.这部分与GitHub Flow中的相同.

然后我的理解是,他们根据是SAAS应用程序还是移动应用程序(可以向世界发布)为我们提供了两个选项.

如果这是SAAS应用程序,我们使用环境分支,例如pre-production和production.这些分支是master在我们准备部署应用程序时创建的.每个环境具有不同的分支允许我们设置CI/CD工具以在对这些分支的提交上自动部署.如果存在关键问题,我们将其修复feature或master分支,然后将其合并到environment分支.

对于可以向世界发布的应用程序(例如移动或桌面应用程序),我的理解是他们建议使用release分支而不是环境分支来使用不同的模型.我们仍在feature分支机构中完成所有工作,并master在完成后将它们合并回分支机构.然后,当我们确保master分支足够稳定时,即我们已经执行了所有测试和错误修复,我们创建release分支并发布我们的软件.如果存在一个关键问题,我们首先在master分支中修复它,并选择修复release分支.

cze*_*win 17

自从这篇文章被提出以来已经过去了一年,但考虑到未来的读者和事实已经发生了一些变化,我认为值得让人耳目一新.

GitHub的流量为最初由斯科特·查孔在2011年描绘的假设,一旦在审查每一个变化feature branch,并入master应立即部署到生产环境.虽然这在当时有效,并且符合唯一的GitHub Flow规则,即主分支中的任何内容都是可部署的,但很快发现,为了保留master已知工作生产代码的真实记录,实际的生产部署应该从在feature branch 之前合并入master.feature branch在任何问题的情况下,从完全意义上进行部署master,可以通过部署来立即恢复生产.请看一下GitHub Flow 的简短视觉介绍.