I'm not a fan. I have never seen a statement of what it gains over gitworkflows(7) and similar (models that prepare releases in 'master', integrate in 'next' w

I'm not a fan. I have never seen a statement of what it gains over gitworkflows(7) and similar (models that prepare releases in 'master', integrate in 'next' which is eventually rewound, and support existing releases via 'maint'). The most critical difference is that git-flow eschews the integration process that allows new features to interact before they are merged to 'master'. Instead of having topic branches tested together in 'next', someone has to be make the difficult decision of whether a topic branch that has only been tested in isolation should be merged into 'develop' (or hotfixes into git-flow's 'master', which is most similar to 'maint' of gitworkflows(7)). This generally means that a git-flow 'develop' is less stable than a gitworkflows(7) 'master', so it's more common to be working on a new feature and find bugs that were there when you started. That's disruptive to development and its unpleasant to users that would really like the latest stuff that you think is actually ready for them to use. Thus any decision to merge a topic branch comes with the pressure that any bugs introduced in the merge (possibly through indirect semantic conflicts with other work) will disrupt any developer starting new work between the merge and the time a fix is provided. In contrast, merging to 'next' in gitworkflows(7) comes with relatively less pressure because bugs there only affect integration and eager users, but not new development. Furthermore, merges to 'master' come with knowledge that the feature has already been playing nicely in 'next', which contains everything in 'master' as well as some other new features. I wrote a more extensive comparison in http://mail-archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.anl.gov http://mail-archive.com/search?l=mid&q=87zjx4x417.fsf@mcs.an...