What is the difference between GitHub Flow and GitLab Flow?

Avinar picture Avinar · Oct 7, 2016 · Viewed 15.9k times · Source

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

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

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

gitlab flow production

gitlab flow environment

gitlab flow release

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?

Answer

Alexey Andrushkevich picture Alexey Andrushkevich · Oct 10, 2016

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.