GitHub Flow 和 GitLab Flow 有什么区别？

Question

最近我在 GIT 中发现了工作流的三个概念：GitFlow、GitHub Flow 和 GitLab Flow。我已经阅读了the nice articles 的相关内容，但我不太了解 GitLab Flow。也许是因为我不是母语人士:)

简单地说。

GitFlow

我们有一个主分支作为生产分支。此外，我们还有一个开发分支，每个开发人员都可以在其中合并他的功能。有时我们会创建一个发布分支来在生产中部署我们的功能。如果我们在发布分支中有错误，请修复它并将更改拉入开发分支。如果我们在生产中遇到严重错误，请创建新的修补程序分支，修复错误并将分支与生产（主）合并并开发分支。

如果我们很少发布我们的工作结果，这种方法很有效。 （可能每 2 周一次）。

GitHub 流

我们有一个主分支作为生产分支。我们（作为开发人员）可以创建用于添加新功能或修复错误的分支，并将它们与生产（主）分支合并。听起来很简单。这种方法适合在一天内多次部署生产分支的极端编程。

GitLab 流程

我见过一些新术语，例如预生产、生产、发布（稳定）分支和暂存环境、预生产环境、生产环境。他们之间有什么关系？

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

如果我们想查看每个单独的功能，这种方法很好；我们只需在分支中签出我们需要查看的内容。

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

我的理解正确吗？

pull 和 cherry-pick 有什么区别？

Answer 1

这篇文章提出已经一年了，但考虑到未来的读者和事实发生了一些变化，我认为值得刷新。

GitHub Flow 作为originally depicted by Scott Chacon in 2011 假设每个更改一旦在feature branch 上审核并合并到master 中，就应该立即部署到生产环境中。虽然这在当时有效并且符合唯一的 GitHub Flow 规则，即 master 分支中的任何东西都是可部署的，it was quickly discovered 为了保持master 的真实记录已知 工作生产代码实际部署到生产应该发生在feature branch 之前将其合并到master。从feature branch 部署非常有意义，因为在出​​现任何问题的情况下，可以通过向其部署master 立即恢复生产。请查看a short visual introduction 到 GitHub Flow。

GitLab Flow 是 GitHub Flow 的一种扩展，附带一组 guidelines and best practices，旨在进一步标准化流程。除了推广准备部署 master 分支和功能分支（与 GitHub Flow 相同）之外，它还引入了其他三种分支：

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

我相信上面的名字和例子都是自我描述的，所以我不会再详细说明了。

Answer 2

GitLab Flow 建议也使用 master 和 feature 分支。一旦功能完成，我们将其合并回master 分支。这部分看起来与 GitHub Flow 中的相同。

那么我的理解是，他们为我们提供了 2 个选项，具体取决于它是 SAAS 应用程序还是移动应用程序（可以向全世界发布）。

如果这是 SAAS 应用，我们会使用环境分支，例如pre-production 和 production。当我们准备好部署我们的应用程序时，这些分支是从master 创建的。每个环境有不同的分支允许我们设置 CI/CD 工具来自动部署对这些分支的提交。如果出现严重问题，我们会在 feature 或 master 分支中修复它，然后将其合并到 environment 分支中。

至于可以发布到世界各地的应用程序（例如移动或桌面应用程序），我的理解是他们建议通过使用 release 分支而不是环境分支来使用不同的模型。我们仍然在feature 分支中完成所有工作，并在完成后将它们合并回master 分支。然后，当我们确保master 分支足够稳定时，即我们已经执行了所有测试和错误修复，我们创建release 分支并发布我们的软件。如果存在严重问题，我们首先在 master 分支中修复它，然后在 release 分支中选择修复。