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

What is the difference between GitHub Flow and GitLab Flow?

提问by Avinar

Recently I've found the three concepts of a workflow in GIT: GitFlow, GitHub Flow and GitLab Flow. I've read the nice articlesabout it but I don't understand GitLab Flow very well. Maybe because I'm not a native speaker :)

最近在 GIT 中发现了工作流的三个概念：GitFlow、GitHub Flow 和 GitLab Flow。我读过关于它的好文章，但我不太了解 GitLab Flow。也许是因为我不是母语人士:)

Briefly.

简要地。

GitFlow

GitFlow

We've a master branch as a production branch. Also we have a develop branch where every developer merges his features. Sometimes we create a release branch to deploy our features in production. If we have a bug in the release branch, fix it and pull changes into the develop branch. If we have a critical bug in production, create new hotfix-branch, fix the bug and merge branch with production (master) and develop branches.

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

This approach works well if we seldom publish results of our work. (Maybe once every 2 weeks).

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

GitHub Flow

GitHub 流程

We have a master branch as a production branch. And we (as developers) can create branches for adding new features or fixing bugs and merge them with production (master) branch. It sounds very simple. This approach fits for extreme programming where the production branch is deployed several times in a day.

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

GitLab Flow

亚搏体育app流

I've seen new terms like a pre-production, a production, a release (stable) branch and a staging environment, a pre-production environment, a production environment. What relationships do they have between them?

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

I understand it this way: If we need to add a new feature we deploy a pre-production branch from the master branch. When we have finished the feature, we deploy a production branch from the pre-production branch. A pre-production branch is the intermediate stage. And then the master branch pulls all changes from the production branch.

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

The approach is good if we want to see each separate feature; we just checkout in the branch what we need to look at.

如果我们想查看每个单独的特征，这种方法很好；我们只是在分行结帐我们需要查看的内容。

But if we need to show our work we create a release branch with a tag as late as possible. If later we fix bugs in the master branch we need to cherry-pick them to the last release branch. At the end we have the release branch with tags that can help us to move between versions.

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

Is my understanding correct?

我的理解正确吗？

What is the difference between pulland cherry-pick?

pull和 和有什么不一样cherry-pick？

采纳答案by Alexey Andrushkevich

GitLab Flowproposes to use masterand featurebranches too. Once feature is done we merge it back to masterbranch. This part looks the same as in GitHub Flow.

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

Then my understanding is that they give us 2 options on how to do it depending on whether it's SAAS app or mobile app (which can be release out to the world).

然后我的理解是，根据是 SAAS 应用程序还是移动应用程序（可以向全世界发布），他们为我们提供了 2 个关于如何执行此操作的选项。

If this is SAAS app we use environment branches e.g. pre-productionand production. These branches are created off the masterwhen we are ready to deploy our application. Having different branches per environment allow us to setup CI/CD tool to automatically deploy on commits made to these branches. If there is a critical issue we fix it in featureor masterbranch and then merge it to environmentbranches.

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

As for applications which can be released out to the world (e.g. mobile or desktop apps) my understanding is that they propose to use different model by using releasebranches instead of environment branches. We still do all work in featurebranches and merge them back to masterbranch upon completion. Then when we make sure that masterbranch is stable enough i.e. we have already performed all testing and bug-fixing we create releasebranch and release our software. If there is a critical issue we first fix it in masterbranch and cherry-pick a fix to releasebranch.

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

回答by czerwin

It has been a year now since this post was raised, but considering future readers and the fact things have changed a bit I think it's worth refreshing.

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

GitHub Flowas originally depicted by Scott Chacon in 2011assumed each change once reviewed on a feature branchand merged into mastershould be deployed to production immediately. While this worked at the time and conformed to the only GitHub Flow rule, which is anything in the master branch is deployable, it was quickly discoveredthat in order to keep mastera true record of known working production codethe actual deployment to production should happen from the feature branchbeforemerging it into master. Deploying from the feature branchmakes perfect sense as in the case of any issue production can be instantaneously reverted by deploying masterto it. Please take a look at a short visual introductionto GitHub Flow.

GitHub的流量为最初由斯科特·查孔在2011年描述假定每一个变化，一旦在feature branch和合并成master应立即部署到生产环境。虽然这在当时有效并且符合唯一的 GitHub Flow 规则，即master 分支中的任何东西都是可部署的，但很快发现，为了保持master已知工作生产代码的真实记录，实际部署到生产应该发生在在feature branch之前合并入master。从 部署feature branch非常有意义，因为在任何问题的情况下，生产都可以通过部署立即恢复master。请看一下GitHub Flow的简短视觉介绍。

GitLab Flowis kind of an extension to GitHub Flow accompanied by a set of guidelines and best practicesthat aim to further standardize the process. Aside from promoting ready to deploy masterbranch and feature branches (same as GitHub Flow) it introduces three other kinds of branches:

GitLab Flow是 GitHub Flow 的一种扩展，伴随着一系列旨在进一步标准化流程的指南和最佳实践。除了宣传准备部署master分支和功能分支（与 GitHub Flow 相同）之外，它还引入了其他三种分支：

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

1. Production分支
2. 环境分支：uat, pre-production,production
3. 发布分支：1-5-stable，1-6-stable

I believe above names and examples are self-descriptive, thus I won't elaborate further.

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