So far, we've explored GitFlow for collaborative project management, but it can be a complex one that doesn't suit all needs. There are alternatives, though, and one of these is posited by GitLab and thus known as GitLab Flow.

GitLab Flow is actually a collection of different branching strategies that can be used depending on your environments and needs. However, they all work on the basis that the master branch is the default branch to merge work into, rather than using a separate develop branch that not all software and CI/CD systems are set up to use by default.

While some development environments can be deployed as soon as commits are merged in, some projects aren't set up like that. A good example is apps that need to be approved by the app store and thus aren't on the same agile, continuous release schedule as the code in the master branch, or platforms that can only be deployed during certain late night/early morning windows so as not to affect the users of the systems:

In this flow, you still have feature branches, but they are branched directly from the master and then merged directly back into the master once they have been completed. After each feature branch is re-merged, it can be safely closed. When you are ready for a deploy—let's say a few feature branches have been merged in and your weekly release is coming up – you simply create a merge commit into the production branch from the master and you have your code ready to go. Enterprising DevOps professionals can set up their continuous integration / continuous deployment systems to detect merges on the production branch and automatically deploy (or package and release) any code that is merged into it.

The production branch workflow is good, but sometimes you have multiple environments and your QA team might want to test stuff a bit further before it gets released. For example, you might have a staging or pre-production environment that you want to deploy to and ensure that everything is working before you deploy to production. In that case, you can use a workflow like the following:

We've trimmed out the feature branches in the preceding diagram, but that part of the workflow would normally remain the same, rather than coding directly onto the master and risking conflicts and merge issues. However, you will notice that rather than merging directly from the master into our production environment, we merge into the staging environment instead. Commits are not done directly in staging either; instead, code must be merged into the master and only then merged back into staging and deployed to the staging environment. Once the release owners are satisfied with everything, a deploy can be made to the production environment by merging from staging into production.

The last flow suggested by the GitLab team is the release branch flow. A handy diagram of it is included as follows:

Once again, we haven't included the feature branches in the diagram, but they are still a key component of this workflow. Differently to the GitFlow, the feature branches merge directly back into the master branch rather than the develop branch. What are new, however, are the release branches, which are named after the release they represent. They are split directly from the master as they are completed. This is a useful branch if you release versioned software. Some people might want to keep access to older versions, or you may need to be able to recreate older versions for troubleshooting purposes or clients on older systems that aren't compatible with later releases.

If you've previously worked with GitHub, you might be familiar with the GitHub flow, a rigid workflow which recommends only having a continuous master branch, from which features are branched off and then merged into when created. Any code in the master branch is theoretically ready for deployment and continuous release with the help of a CI/CD platform:

The main difference between the GitHub and GitLab flows is the flexibility of the latter. It provides blueprints for a number of different scenarios, each with slight differences in environment setup to cater to your project's needs. GitLab also avoids recommending the master for use in deployments, which can reduce the risk of bugs and ill effects being deployed.