GitHub Flow和GitLab Flow有什么区别？

Question

最近我在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 Flow（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）。

我已经看到像预生产，生产，发布（稳定）分支和临时环境，预生产环境和生产环境这样的新术语。他们之间有什么关系？

我明白这一点：如果我们需要添加一个新功能，我们会从主分支部署一个预生产分支。当我们完成该功能后，我们从预生产分支部署生产分支。预生产分支是中间阶段。然后主分支从生产分支中提取所有更改。

如果我们想要查看每个单独的功能，该方法很好。我们只需在分支中签出我们需要和看的东西。

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

我的视力正确吗？ 拉和樱桃采摘有什么区别？

Answer 1

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分支。

Answer 2

自从这篇文章被提出以来已经过去了一年，但考虑到未来的读者和事实已经改变了一些，我认为这值得提神。

GitHub的流量为originally depicted by Scott Chacon in 2011假设一旦在feature branch审查每一个变化和合并为master应立即部署到生产环境。虽然这个工作的时候，符合唯一GitHub的流动规律，这是任何在主分支部署，it was quickly discovered，为了保持master知真实记录工作的生产代码实际部署到生产中应发生在feature branch之前合并到master。从feature branch进行部署非常有意义，因为在任何问题产生的情况下，都可以通过部署master进行即时恢复。请看看GitHub Flow的a short visual introduction。

GitLab流程是对GitHub Flow的扩展，附带一组guidelines and best practices，旨在进一步标准化流程。除了促进准备部署master分支和功能分支（同GitHub的流量），它引入了另外三种分支：

1. Production branch
2. Environment branches：uat，pre-production，production
3. Release branches：1-5-stable，1-6-stable

我相信上面的名字和例子是自描述的，因此我不会详细说明furt她的。