Mar 5, 2020 - Suri Patel    

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. Because most tools default to using the master, there’s a significant amount of branch switching involved. Another frustrating aspect is hotfix and release branches, which are overkill for most organizations and completely unnecessary in companies practicing continuous delivery.

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

GitLab Flow: a simplified branching strategy

GitLab Flow 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 a way 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 production. 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/hot fix patches are cherry-picked from master

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 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 blog is worth a read in its entirety, but here are a few rules are timely reminders of the importance of test, 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

Free eBook: The benefits of single application CI/CD Download the ebook to learn how you can utilize CI/CD without the costly integrations or plug-in maintenance. Learn more Arrow

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab for Free

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg