What is the difference between GitHub Flow and GitLab Flow?

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.

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.