Hace cinco años ya resaltamos los problemas de las ramas de larga duración con Gitflow. En esencia, este tipo de ramas son lo contrario a integrar de forma continua todos los cambios del código fuente y, en nuestra experiencia, la integración contínua es el mejor enfoque para la mayoría de los proyectos de desarrollo de software. Un tiempo después, extendimos nuestra advertencia al mismo Gitflow porque observamos que algunos equipos lo usaban exclusivamente con ramas de larga duración. Hoy en día, aún hay equipos en entornos donde se tiene como objetivo hacer entrega continua de sistemas para la web, que se ven forzados a usar ramas de larga duración. Por ello, saludamos que el autor de Gitflow haya añadido una nota a su artículo original, explicando que Gitflow no estaba pensado para dicho uso.
Gitflow is a strict branching pattern for releases using Git. Although not an inherently bad pattern, we often see it misused. If the feature and develop branches are short lived and merged often, you are really using the power of Git, which makes these activities easy. However, a problem we often see is that these become long lived branches , which results in the dreaded merge conflicts many people began using Git to escape. A merge is a merge. Regardless of the source control tool or pattern you use. If you wait more than a day or two to merge, you could hit a big merge conflict. This becomes a real issue if you have a larger team. If you have more than a few people waiting to merge, you can have a serious a bottleneck. Introducing patterns like Gitflow require the discipline to merge often to be successful. So by all means use the pattern, but only if you have the discipline to prevent long lived branches
