Git Flows and modern deployment pipelines

Traditional Git Flow

The first and the oldest approach which is still very popular and legit. It assumes, that you have a master and a develop branch. Master is supposed to be deployed to production having always the stable state and develop for any possible mess except that.

This picture is still hanging on the walls of many IT departments
  • Hard to plan releases. You have to deploy everything which is inside develop.

GitHub Flow

As you could guess, there is a much easier way to work with branches, which also fits very well for continuous delivery: when you work only with the master and feature branches. Once a feature is ready, it gets merged into master, tested and immediately deployed.

GitLab Flow and Microsoft Release Flow

GitLab tried to keep simplicity of Github flow but at the same time to introduce a possibility to prepare normal releases. So they (or Microsoft, to be honest I don’t know who was the first) came up with idea of environment branches in terms of GitLab and Release Branches in terms of Microsoft. And the same similar idea underlies OneFlow: you work on your master branch using feature branch as you would with GitHub flow, but just before your release you create a release branch (or environment branch from GitLab. They are can be multiple btw, e.g staging and production, and one is getting branched further from the previous one). Doing that you kind of freeze your code state in case the deployment can take time (e.g you are waiting for an approval from third-party provider or just test the release couple of days), so it doesn’t prevent from further development in master.


GitLab and Microsoft tricky suggest to use cherry-picking (they even made UI for that in Azure DevOps and GitLab). The idea is that you make hotfixes always and only in master, so you protect yourself from forgetting to merge back that hotfix to master. So once you made a hotfix to master, you cherry-pick it to the appropriate release/environment branch. Hm? For me it sounds beautiful and ugly at the same time.

  • Coupling with the platform (cherry picking UI and deep integration of Git Flow to deployment processes)
  • Still poor release planning

So what’s with release planning?

So as we could see, none of these major Git Flows suggests long-term planned releases. Long-term planned release means, that just before a production deployment there is no need to review develop/master branch, searching for feature which should not be deployed in this release. It means, that we have a dedicated branch with exact features, ready for deployment. Yes, it might be challenging to plan everything correctly, but it brings a lot of good structuring and order to the development process. It works also pretty well along with Scrum sprints and planning. Besides that, you can run 2 parallel release branches and develop independently heavy features.

  • You have to plan really well


There is no best and worse Git Flow, in order to choose one for your project, try to consider following points:

  • Can you more or less precisely plan releases in advance?
  • Which automation tool are you going to use. GitLab and Microsoft Flows are pretty good implemented to their platforms



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store