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