Simplified Git Flow: An Improved Git Flow for Continuously-Delivering Projects
date
Mar 1, 2022
slug
simplified-git-flow
status
Published
tags
Git
Git Flow
summary
Git Flow is often considered as one of the most popular Git Workflow out there. But this does not come without controversies. Learn about the controversies of Git Flow, and how Simplified Git Flow might be a better fit for your software project.
type
Post
In summary, Git Flow should not be an absolute go-to when it comes to choosing a Git workflow for a team-based developments. This is due to the fact that Git Flow can be too complex for some projects, making the development process less efficient as a consequence of having to go through all the unnecessary ceremonial procedures.
There are many alternatives of Git Flow, but to be able to keep the benefits of Git Flow, whilst having a simpler flow, one could go with Simplified Git Flow.
What is Git Workflow?
Git, as world’s most popular VCS (version control system), has some sort of ‘recommendation’ as a means of guiding users on how it should be operated. This so-called recommendation is often referred as Git workflow.
A Git workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner.
— Comparing Workflows by atlassian.com
And when one talks about Git workflow, there are lots of ‘recipe’ out there adjusted for any development situation.
Many Shades of Git Workflow
As mentioned above, there are tons of many different workflow that can be implemented in each of our software projects. Ranging from Git Flow to Trunk-based Development, in which you can read about it further in the articles below.
But we won’t be talking about the many-spices of Git workflow. Instead, we’re gonna talk about one of the more famous Git workflow, which is Git Flow, and how we can make it a better-fit in some cases.
What is Git Flow?
The Git Flow model was first popularized by Vincent Driessen on his blogpost with the title A Successful Git Branching Model. Coming from Driessen’s own experience of success upon implementing this kind of Git development model, he then decided to refine it up to the point that his model is known as Git Flow.
In this post I present the development model that I’ve introduced for some of my projects (both at work and private) about a year ago, and which has turned out to be very successful.
— A Successful Git Branching Model by Vincent Driessen
To put it simply, Git Flow consists of main branches and supporting branches. The description of each branches are as follows:
masterbranch → Serves as a main branch and has infinite lifetime
developbranch → Serves as a main branch and has infinite lifetime
release-*branch → Serves as a supporting branch
feature-*branch → Serves as a supporting branch
hotfix-*branch → Serves as a supporting branch
The
-* suffix indicates that the number of branches that can be created is unlimited according to our needs. Meanwhile, the flow of the development is as explained on the image below.
To summarize the image above, here are some key takeaways regarding the development flow of Git Flow:
developbranch branches off frommasterbranch
feature-*branches only branch off from and being merged todevelopbranch
release-*branches are created fromdevelopbranch and being merged tomasterbranch
masterbranch is given a tag for every mergedrelease-*branch
hotfix-*branch only branches off frommasterbranch and incorporated todeveloponce the bug is solved
The explanation above is the traditional approach of Git Flow, taken from Driessen’s very first publication about Git Flow. To this date, there are some adaptations of Git Flow with slight modification, such as the addition or the renaming of
develop branch into staging, the addition of coldfix branch, etc.
At a glance, the Traditional Git Flow may look a little too complicated, especially for software projects that deliver working products often. Hence, there comes a need for a simpler flow while still maintaining the tidiness of the repository and the ability to be able to do a large amount of separate developments at the same time.
Controversies of Git Flow
Despite being one of the most used Git workflow, the complexity of the model presented by Git Flow—as already mentioned before—can be a hassle for some projects. For example, a smaller-scale product with short span of time in-between releases. Making it clear that Git Flow is not an absolute solution for every software projects.
Regardless of that, there are still some project that forces the usage of Git Flow for such case, making the development process is pained by the unnecessary ceremonials of Git Flow. Even the inventor of Git Flow himself, had admitted that his creation after 10 years has grown into a dogma within the world of developers.
This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.
— A Successful Git Branching Model by Vincent Driessen
As a solution of the stated issue above, Driessen also added this statement:
This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.
— A Successful Git Branching Model by Vincent Driessen
Aside from the issues mentioned above, there are also some other critics addressed to Git Flow. One of them is from an article by George Stoker titled Please Stop Recommending Git Flow!
Introducing: Simplified Git Flow
Based on the explanation from the previous section, it can be concluded that there are many alternatives to Git Flow out there. But when it comes to having a simpler version of Git Flow, whilst maintaining the cleanliness of the repository, and the capability to accommodate multiple development at the same time, one could go with Simplified Git Flow.
This model is proposed by Kevin Kuchta, through his article Simplified Git Flow.
While you can just go ahead and visit the article for a more comprehensive explanation, I’m gonna give you some main differences between the Traditional Git Flow and the Simplified Git Flow. Here are the main differences as written by Kuchta:
- The
masterbranch is always deployed
- The
developbranch is always ready to deploy.
developis merged tomasterand deployed every morning (and as-needed after that if someone’s willing to go through the 30 minute deploy process).
- Small personal branches off of
developare merged back into it regularly, using feature flags to release larger features.
- Long-lived feature branches are still possible for features that are impractical to release piecemeal, but are discouraged.