The Illusion of a Clean Hotfix Workflow
A seemingly textbook Gitflow pipeline, designed for clean development and promotion through staging environments to production, can unravel spectacularly when a critical bug surfaces. The common scenario involves a development branch feeding a release branch, with a single build artifact promoted sequentially through dev, QA, SIT, UAT, and finally, production. A successful production deployment is then followed by tagging the commit on the main branch. This structure appears robust on paper, promising predictability and control.
However, reality often diverges from the diagram. The standard procedure for a production bug involves branching a hotfix from the production tag. This hotfix is then PR'd back into the release branch, run through the entire pipeline, and upon successful UAT validation, merged into main and subsequently cherry-picked back into the develop branch. This process, while functional, harbors a critical, often unacknowledged, flaw: the release branch itself. By the time a hotfix is needed, the release branch may contain significant, untested code changes from ongoing feature development. These are features that might be deep into QA or even UAT on separate tracks but are now sitting on the same branch that the hotfix must traverse. This creates a fundamental conflict: do you trust this potentially unstable release branch to carry your critical hotfix through all stages, or do you bypass it, creating a different kind of pipeline smell?
The Core Conflict: Trusting the Release Branch
The real argument surfaces not around the mechanics of releasing a hotfix, but around the integrity of the release branch itself. If the release branch is a moving target, containing features that are not yet fully validated or understood, then routing a hotfix through it becomes a gamble. The intention of a release branch is to stabilize a version of the code for deployment. When that branch is contaminated with unproven code from later development cycles, its purpose is undermined. Developers and release managers face a dilemma: either subject the hotfix to the risks of an unstable branch, potentially introducing new issues, or find an alternative path that deviates from the established Gitflow pattern.
Consider the state of the release branch when a hotfix is initiated. It likely contains not only the code that was stable enough for the last production release but also significant portions of code from ongoing feature development. These features might be in various stages of testing, some potentially failing or in flux. When you cherry-pick a hotfix into this environment, you are essentially layering a critical fix onto a foundation that may not be sound. The pipeline, designed to ensure stability through sequential testing, is compromised because the starting point for the hotfix is no longer the last known good state, but a mixed bag of stable code and experimental features.
The 'Twice Cherry-Picked' Problem
The situation is exacerbated when the hotfix needs to be applied to multiple active branches, a common scenario in Gitflow. The hotfix is first cherry-picked from the production tag into the release branch. After it passes through the pipeline, it's merged into main and then cherry-picked into the develop branch. This second cherry-pick is where the true pipeline smell intensifies. The develop branch is, by definition, the bleeding edge, a place where new features are integrated and may still be unstable. Applying a hotfix here, after it has already traversed a potentially compromised release branch, introduces complexity and increases the risk of regressions.
The problem isn't just about applying a fix; it's about how that fix interacts with the ongoing development. When a hotfix is cherry-picked into develop, it lands in a branch that may have diverged significantly from the state it was in when the hotfix was originally tested on the release branch. This can lead to subtle conflicts or unexpected behavior that only manifest later, possibly during the next planned release cycle. The confidence gained from passing the hotfix through the pipeline on the release branch is partially eroded by the act of reintroducing it into the volatile develop branch. This dual cherry-picking, while a common workaround, highlights a systemic issue in managing hotfixes within traditional Gitflow when development outpaces release stability.
Rethinking the Release Strategy
The underlying issue points to a need to re-evaluate release strategies and the definition of a