Warum ich Git-Flow lieber doch nicht benutzen werde

Letzte Änderung am 28. Dezember 2021 by Christoph Jüngling

Über Git Flow habe ich in letzter Zeit so einiges geschrieben, und eigentlich wollte ich noch einen längeren Artikel darüber bringen. Daraus wird nun nichts.

Vor kurzem unterhielt ich mich mit einem Kollegen darüber, der schon sehr viel länger als ich mit Git arbeitet. Er hatte sich aufgrund dieses von ihm empfohlenen Artikels dagegen entschieden. Ich kann viele der dort geäußerten Bedenken nachvollziehen, insbesondere die zu der lesbaren Historie. In meinem konkreten Projekt ist eines aber ein echtes K.O.-Kriterium: Bugfix-Releases können gemäß Git Flow nur auf dem letzten Release-Stand durchgeführt werden. Ich will kurz zeigen, dass das (jedenfalls mit Git Flow v1.9.1) nicht geht.

Gemäß Git Flow soll der Befehl “git flow hotfix start <name> <base>” aus einem releasten Stand einen Hotfix-Branch abzweigen, in dem ein Fehler einer früheren Version behoben wird. Leider funktioniert das nur, wenn besagte „frühere Version“ zugleich auch die letzte Version ist, die releast wurde, wenn ich den alten Stand auschecke und die “<base>” weg lasse.

Gebe ich sie an, sieht es so aus:

$ git flow bugfix start v1.1 v1.0
Fatal: Base 'v1.0' needs to be a branch. It does not exist and is required.

Der Befehl sollte einen Bugfix-Branch mit Namen “v1.1” beginnen, der auf dem Stand von v1.0 basiert. Der Meldung zufolge akzeptiert Git Flow jedoch als Basis nur Branches, keine Tags. Auch mit “hotfix” statt “bugfix” funktioniert es nicht. Und da sowohl Git empfiehlt, alte Branches zu löschen, als auch Git Flow dies automatisch durchführt, ist nicht zu erwarten, dass ein solcher Branch noch existiert.

Damit ist  für mich die Entscheidung gefallen. Zwar finde ich den gedanklichen Ansatz nach wie vor interessant, aber im konkreten Projekt sind Hotfixes leider notwendig. Auch in anderen Projekten möchte ich mir nicht vorab die Möglichkeit verbauen, dies mal zu benötigen.

Ich bleibe daher bei dem üblicherweise empfohlenen Git-Workflow.

Ähnliche Artikel:

1 Kommentar

3 Pings

  1. Wenn du ein älteres Release mit Hotfixes (oder sonst wie) supporten möchtest, brauchst du nach dem Git-Flow-Modell (und jedem anderen mir bekannten Modell, dass mehrere Releases parallel unterstützt) natürlich einen Support-Branch. Master kannst du ja nicht nehmen.

    (develop)$ git flow support start 0.1 0.1

    (support/0.1)$ git flow hotfix start 0.1.1 support/0.1

    #do the fix, add, commit

    (hotfix/0.1.1)$ git flow hotfix finish

    support/0.1 kann dann spätestens wieder gelöscht werden, sobald der Support für 0.1 ausgelaufen ist.

    Falls dein git flow keine Support-Branches kann, kannst du den benötigten Branch auch einfach manuell anlegen.

  1. […] den aktuellen Artikel […]

  2. […] den aktuellen Artikel […]

  3. […] den aktuellen Artikel […]

Schreibe einen Kommentar

Deine Email-Adresse wird nicht veröffentlicht.

elf + siebzehn =