Há cinco anos, destacamos os problemas com branches de longa duração com Gitflow. Essencialmente, branches de longa duração são o oposto da integração contínua de todas as alterações no código-fonte e, em nossa experiência, a integração contínua é a melhor abordagem para a maioria dos tipos de desenvolvimento de software. Mais tarde, estendemos nossa cautela ao próprio Gitflow, porque vimos equipes usando-o quase exclusivamente com branches de longa duração. Hoje, ainda vemos times com configurações nas quais a entrega contínua de sistemas baseados na web é o objetivo declarado sendo atraídos para branches de longa duração. Por isso, ficamos felizes com o fato de o autor do Gitflow ter adicionado uma nota ao seu artigo original, explicando que o Gitflow não se destinava a esses casos de 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
