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