What is Gitflow, Anyway?
At its heart, Gitflow is a strict set of rules for managing code changes in a software project. Imagine a highly organized office with separate inboxes for everything. There’s a 'main' branch, which holds only official, production-ready code. A parallel
'develop' branch acts as an integration area for new work. Then you have temporary branches for every 'feature', 'release', and emergency 'hotfix'. The idea, introduced by Vincent Driessen in 2010, was to bring order to complex development cycles by giving every type of change a designated path. This structure was meant to ensure the main branch is always stable and releasable.
The Birth of a Specific Workflow
To find the 'hidden practice,' you have to go back to Gitflow's origin. It wasn't designed in a vacuum. It was created for a specific type of software development: projects with explicit, versioned releases. Think about traditional desktop software or mobile apps where you need to support version 1.0, 1.1, and 2.0 all at the same time. The intricate system of release and hotfix branches makes perfect sense in this world. It allows a team to prepare for version 1.2 while simultaneously patching a critical bug in version 1.1.4 without the two streams of work ever interfering. This careful segregation is the problem Gitflow was built to solve.
The 'Hidden Practice' Everyone Misses
Here's the reveal: the hidden practice isn't a secret Git command. It's the practice of having a project that actually requires this level of version management. The entire model is built on the assumption that you are shipping distinct, numbered versions of your software to users and may need to maintain older ones. For years, teams adopted Gitflow because it looked professional and structured, without asking if they shared the same core problem. They adopted the solution without having the corresponding issue, like buying industrial-grade construction equipment to hang a picture frame.
The Trouble with Gitflow Today
The mismatch becomes obvious in the world of modern web applications and continuous deployment. For most web apps, there is only one version that matters: the one currently live in production. The goal is to get small, incremental changes out quickly and safely, not to batch them up for a big quarterly release. In this context, Gitflow's complexity becomes a significant disadvantage. The ceremony of creating release branches and back-merging fixes introduces unnecessary overhead, slows down delivery, and can increase the frequency of complex merge conflicts. It's a structured, heavyweight process in an environment that demands speed and simplicity.
Simpler Paths Forward
Recognizing this friction, the industry has largely shifted toward simpler models for web development. Workflows like GitHub Flow and Trunk-Based Development are far more lightweight. GitHub Flow, for example, typically uses a single main branch that is always deployable. Features are developed on short-lived branches and merged directly back into main upon completion, triggering an immediate deployment. This model aligns perfectly with continuous delivery, removing the administrative burden of Gitflow and allowing teams to focus on shipping value faster. Even Gitflow's creator has noted that for many modern projects, a simpler approach is likely better.
