Blog Open Source The problem with Git flow
March 5, 2020
5 min read

The problem with Git flow

Learn why Git flow complicates the lifecycle and discover an alternative to streamline development.


Sometimes, you can have too much of a good thing. That’s certainly true with Git flow, a well-known software development workflow that offers several options but can bog down users.

We developed GitLab Flow as the solution to eliminate messy complexity and streamline the development process. GitLab Flow brings issue tracking to the Git workflow, simplifying the process and removing confusion.

The problem with Git flow

To understand how GitLab Flow works, it’s helpful to start by looking at the problems it tries to solve. In Git flow, there are two main pain points, both of which involve unnecessary branch switching.

Git flow forces developers to use the develop branch rather than the master or default branch. Because most tools default to using the master, there’s a significant amount of branch switching involved. Another frustrating aspect are release and hotfix branches, which are overkill for most organizations and completely unnecessary in companies practicing continuous integration and continuous delivery.

That brings us to GitLab Flow, a simpler workflow and branching model that keeps everything simple and inclusive.

GitLab Flow: a streamlined branching strategy

GitLab Flow is a simpler alternative to Git flow that combines feature-driven development and feature branches with issue tracking. GitLab Flow integrates the Git workflow with an issue tracking system, offering a simple, transparent, and effective way to work with Git.

GitLab Flow is an approach to make the relationship between the code and the issue tracker more transparent. Each change to the codebase starts with an issue in the issue tracking system. When you’re done coding or want to discuss the code, you can open a merge request. When the code is ready, the reviewer will merge the branch into master, creating a merge commit that makes this event easily visible in the future. Using GitLab Flow, teams can deploy a new version of code by merging master into a production branch, enabling them to quickly identify what code is in the production environment. In this workflow, commits only flow downstream, ensuring that everything is tested in all environments.

GitLab Flow prevents the overhead of releasing, tagging, and merging that accompanies Git flow.

GitLab Flow in a nutshell:

  • All features and fixes first go to master
  • Allows for production or stable branches
  • Bug fixes/hotfix patches are cherry-picked from master

Read more on here GitLab Flow best practicies

Breaking down the 10 stages of software development

GitLab Flow is a way to move from the idea stage to production, all while keeping everyone informed and productive. We identified 10 key stages of the development process that must happen in order for software to get into production. GitLab Flow makes it easy to account for all of them, while continuing to provide full visibility into the development lifecycle.

Broadly speaking, GitLab Flow is broken down into three main areas: feature branch, production branch, and release branch.

A feature branch is where the serious development work occurs. A developer creates a feature or bug fix branch and does all the work there rather than on a master branch. Once the work is complete, the developer creates a merge request to merge the work into the master branch.

The production branch is essentially a monolith – a single long-running production release branch rather than individual branches. It’s possible to create a tag for each deployable version to keep track of those details easily.

The last piece, the release branch, is key if you release software to customers. With every new release, you’ll create a stable branch from master and decide on a tag. If you need to do a patch release, be sure to cherry-pick critical bug fixes first, and don’t commit them directly to the stable or long-lived branch.

Follow the rules

Want to get the most out of GitLab Flow? Our CEO Sid Sijbrandij came up with 11 rules teams should always follow to achieve maximum efficiency. The article is worth a read in its entirety, but here are a few rules that are timely reminders of the importance of testing, even in a CI environment:

  • Test all commits: Don’t wait to test until everything has been merged into master. Test commits along the way to catch problems earlier in the process.
  • And run all tests on all the commits, even if you have to run tests in parallel.
  • Code reviews > merging into master. Why wait? "Don’t test everything at the end of the week," Sid writes. "Do it on the spot, because you'll be more likely to catch things that could cause problems, and others will also be working to come up with solutions."

Take a deep dive

Take a look at GitLab Flow in action! 🍿

Cover image by Fabio Bracht on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert