git - GitHub Flow 和 GitLab Flow 有什么区别？

Question

最近我在 Git 中发现了工作流的三个概念:

• GitFlow
• GitHub 流程
• GitLab 流程

我读过 the nice articles关于它，但我不太了解 GitLab Flow。

简单地说。

GitFlow

我们有一个主分支作为生产分支。我们还有一个开发分支，每个开发人员都在这里 merge 他的功能。有时我们会创建一个发布分支来在生产环境中部署我们的特性。如果我们在发布分支中有错误，请修复它并将更改 pull 入开发分支。如果我们在生产中有一个严重的错误，创建新的修补程序分支，修复错误并将分支与生产(master)和开发分支 merge 。

如果我们很少发布我们的工作结果，这种方法会很有效。 (也许每 2 周一次)。

GitHub 流程

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

GitLab 流程

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

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

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

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

我的理解正确吗？

pull 和 cherry-pick 有什么区别？

Answer 1

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

GitHub 流程 为 originally depicted by Scott Chacon in 2011假设每个更改一旦在 feature branch 上审查并 merge 到 master 中，就应该立即部署到生产环境中。虽然这在当时有效并且符合唯一的 GitHub Flow 规则，即 master 分支中的任何内容都是可部署的，it was quickly discovered为了保持 master 已知工作生产代码 的真实记录，实际部署到生产应该从 feature 分支 之前发生 将其 merge 到 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-稳定, 1-6-稳定

我相信以上名称和示例是 self 描述的，因此我不会进一步详细说明。