Recently I’ve found three concepts of a workflow in Git:
- GitHub Flow
- GitLab Flow
I’ve read the nice articles about it but I don’t understand GitLab Flow very well.
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).
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.
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
GitLab Flow proposes to use
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.
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
master branch and then merge it to
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
Answered By – Alexey Andrushkevich