What is the difference between GitHub Flow and GitLab Flow?

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

Briefly.

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).

GitHub Flow

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.

GitLab Flow

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.

Is my understanding correct?

What is the difference between pull and cherry-pick?

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 Flow as originally depicted by Scott Chacon in 2011 assumed each change once reviewed on a feature branch and merged into master should 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 discovered that in order to keep master a true record of known working production code the actual deployment to production should happen from the feature branch before merging it into master. Deploying from the feature branch makes perfect sense as in the case of any issue production can be instantaneously reverted by deploying master to it. Please take a look at a short visual introduction to GitHub Flow.

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

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

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

GitLab Flow proposes to use master and feature branches too. Once feature is done we merge it back to master branch. This part looks the same as in 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).

If this is SAAS app we use environment branches e.g. pre-production and production. These branches are created off the master when 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 feature or master branch and then merge it to environment branches.

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 release branches instead of environment branches. We still do all work in feature branches and merge them back to master branch upon completion. Then when we make sure that master branch is stable enough i.e. we have already performed all testing and bug-fixing we create release branch and release our software. If there is a critical issue we first fix it in master branch and cherry-pick a fix to release branch.