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