In previous article, I have provided brief overview of Gitflow workflow. We have seen that one of the major disadvantages of Gitflow workflow is its complexity. In this article, we are going to have a look at simpler branching strategies – the GitHub flow and the Gitlab flow.
This is very simple branching strategy. In this strategy, there are only two kinds of branches
- master (or main) branch – which contains all the code
- feature branches, which are created from master (or main). Once the backlog item / story is done, the feature branch is merged back to master (or main) and it is deleted.
Here the assumption is the main branch is always ready for deployment. This flow is very much straightforward. It is very useful when the release cycles are shorter and it seems to be in line with lean and continuous integration and continuous delivery best practices.
This flow does not have any specific guidance about the environments and releases. This means we can extend it further based on needs of the project. For example, we can design a process to create release branches whenever we deliver to decide to deploy newer version to production. Then we can decide to keep past few release branches.
The Gitlab flow extends the GitHub flow further. The Gitlab flow is very useful when there are multiple environments and there may be a need of having a separate release branch (or environment specific branch).
For example, android or iOS application is released only when the validation passes. This may take few days. Till the result is not know, we may want to have a separate release branch for this.
In the Gitlab flow, we can have a separate production branch which holds the code which is deployed to the production. In fact, we can have one branch for each environment where application will be deployed.
These strategies are simpler and may help to reduce the efforts required for managing releases and release branches. Have you tried these strategies already ? What are your opinions about these ? Let me know your thoughts.