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
productionorstablebranches - 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
