Gitflow für Release-Management mit traditionellen Kunden

Traditionelle Kunden wollen drei Dinge gleichzeitig.

Sie wollen flexibel bleiben und mitten im Projekt ihre Meinung ändern können. Sie wollen feste Release-Termine. Sie wollen feste Preise.

In einem Lenkungskreis klingt das vernünftig. In der Umsetzung ist es ein Konflikt.

Wenn jede neue Idee in das nächste Release kann, ist der Termin nicht fest. Wenn der Termin fest ist, kann nicht jede neue Idee in das nächste Release. Man kann so tun, als gäbe es diese Spannung nicht. Die Codebasis interessiert das nicht.

Gitflow ist nicht modern. Es ist nicht der schnellste Weg, Software auszuliefern. Aber bei traditionellen Kunden löst es ein echtes Problem: Es macht Release-Umfang sichtbar.

Sichtbarer Umfang verhindert, dass Projekte mit festen Terminen zu wöchentlichen Nachverhandlungen werden.

Was Gitflow dir wirklich gibt

Gitflow ist ein Branching-Modell mit klaren Aufgaben für klare Branches.

• main ist Produktion
• develop ist die nächste Version in Arbeit
• feature branches sind isolierte Arbeitspakete
• release branches sind die Version, die stabilisiert wird
• hotfix branches sind dringende Produktionsfixes

Wenn du eine schnelle visuelle Übersicht willst, ist Daniel Kummers Gitflow Cheatsheet immer noch die Seite, die ich öffne.

Der nützliche Teil ist nicht der Name der Branches. Der nützliche Teil ist die Trennung der Absicht.

Code auf develop heißt: Das wird vorbereitet.

Code auf einem release Branch heißt: Das wird gehärtet.

Code auf main heißt: Das ist live.

Niemand muss fragen, ob eine Funktion am Freitag rausgeht. Der Branch beantwortet die Frage.

Warum traditionelle Kunden diese Klarheit brauchen

Kunden aus Banken, Versicherungen, Industrie, öffentlichem Sektor oder Festpreisumfeldern denken meist nicht in Continuous Deployment.

Sie denken in Releases.

Sie müssen wissen, wofür sie zahlen, wann es live geht und was passiert, wenn sich das Geschäft zwei Wochen vor Go-live umentscheidet.

Gitflow gibt dir eine Struktur für dieses Gespräch.

Der Release-Branch wird zu dem Punkt, auf den alle zeigen können.

Das ist das Release.

Das darf sich noch ändern.

Das wandert ins nächste Release.

Traditionelle Kunden kaufen nicht nur Software. Sie kaufen Planbarkeit: Freigaben, Schulungspläne, Rollout-Fenster, Support-Vorbereitung, manchmal sogar regulatorische Abnahmen.

Wenn dein Release-Prozess unscharf ist, bricht ihr interner Prozess.

Der Ablauf, den ich in der Praxis nutze

Der Rhythmus ist einfach.

Eine neue Funktion startet auf einem Feature-Branch von develop.

Wenn sie durch das Review ist, wird sie zurück nach develop gemergt. Aus Entwicklungssicht ist sie dann fertig, aber noch nicht ausgeliefert.

Etwa zwei Wochen vor dem vertraglichen Release-Termin wird develop in einen versionierten Release-Branch abgezweigt.

Ab diesem Moment ändert sich die Regel.

Kein neuer Umfang kommt in den Release-Branch. Nur Bugfixes, Stabilisierung, Dokumentationskorrekturen und release-kritische Anpassungen.

Der Release-Branch wird getestet, freigegeben, nach main gemergt, getaggt und ausgeliefert.

Alles andere geht nach develop.

Das ist der Satz, der das Projekt rettet:

“Das kommt ins nächste Release, nicht in dieses.”

Nicht weil das Team schwierig ist. Sondern weil das aktuelle Release in der Stabilisierung ist und eine Änderung jetzt das Risikoprofil verändert.

Traditionelle Kunden können das akzeptieren. Was sie nicht akzeptieren können: einen Tag vor Go-live zu erfahren, dass das Release instabil ist, weil fünf “kleine Änderungen” unbemerkt hineingerutscht sind.

Kleine Änderungen sind am Ende eines Releases selten klein.

Gitflow als Kommunikationswerkzeug

Die meisten Teams sprechen über Gitflow als Entwickler-Workflow.

Damit verpassen sie die Hälfte des Werts.

Gitflow ist auch ein Kommunikationswerkzeug. Es gibt Projektmanagern, Kunden, QA und Entwicklern eine gemeinsame Sprache für den Release-Zustand.

Du kannst sagen:

• “Das ist schon im Release-Branch.”
• “Das ist in develop gemergt, aber nicht Teil des aktuellen Releases.”
• “Das ist ein Hotfix und berührt das nächste geplante Release nicht.”
• “Das ist ein neues Feature und muss auf das nächste Release-Fenster warten.”

Das sind keine technischen Details. Das sind kommerzielle Grenzen.

Sie schützen das Team vor verstecktem Scope Creep, den Kunden vor überraschenden Verzögerungen und die Beziehung vor dem üblichen Drama am Projektende.

Wo Gitflow das falsche Werkzeug ist

Gitflow ist schwergewichtig.

Wenn dein Team zehnmal am Tag ausliefert, nutze es nicht. Wenn dein Produkt auf Continuous Delivery, Feature Flags, automatisierten Tests, schnellem Rollback und guter Beobachtbarkeit läuft, ist Trunk-Based Development meist besser.

Die Branche hat sich aus guten Gründen in diese Richtung bewegt: schnelleres Feedback, kleinere Änderungen, weniger Branch Drift, weniger schmerzhafte Merges.

Aber nicht jeder Kunde lebt in dieser Welt.

Nutze Gitflow, wenn:

• Du nach Kalender auslieferst, nicht sobald die Pipeline grün ist
• Der Kunde einen stabilen Release Candidate zum Testen braucht
• QA oder Compliance Tage brauchen, nicht Minuten
• Release-Umfang vertraglich relevant ist
• Der Kunde vor Go-live eine formale Abnahme erwartet
• Dein Team klein genug ist, damit langlebige Branches nicht zur Merge-Konflikt-Fabrik werden

Für die meisten Teams liegt diese Grenze irgendwo unter 30 aktiven Entwicklern. Danach kann Gitflow schnell teuer werden.

Der Fehler, den du vermeiden solltest

Versteck dich nicht hinter Gitflow.

Ein Prozess repariert keine schlechte Planung, unklare Verantwortung oder einen Kunden, der ständig den Umfang ändert, aber Termine und Budget nicht bewegen will.

Gitflow funktioniert nur, wenn du es nutzt, um Entscheidungen explizit zu machen.

Wenn ein Release-Branch geschnitten wird, müssen Team und Kunde verstehen, was das bedeutet. Neuer Feature-Umfang ist nicht “fast dabei”. Er ist draußen. Es sei denn, es gibt eine bewusste Entscheidung, das Release zu ändern.

Diese Entscheidung hat Kosten.

Vielleicht verschiebt sich der Termin. Vielleicht fallen andere Features raus. Vielleicht ändert sich das Budget. Vielleicht wird das Risiko schriftlich akzeptiert.

Aber es ist jetzt eine Entscheidung, keine Überraschung später.

Die eigentliche Lektion

Der Workflow ist nicht der Punkt.

Der Punkt ist Release-Umfang.

Traditionelle Kunden brauchen eine klare Antwort auf eine Frage:

“Was ist im nächsten Release, und was nicht?”

Wenn du das ohne Zögern beantworten kannst, bist du vielen Teams voraus.

Gitflow ist eine Möglichkeit, die Antwort offensichtlich zu machen. Nicht weil es modern ist. Nicht weil es elegant ist. Sondern weil es gut zu Kunden passt, die Software noch in Release-Paketen kaufen, Abnahmedokumente unterschreiben und Rollouts um Kalendertermine herum planen.

Viele dieser Kunden zahlen immer noch sehr gut.

Ja, Trunk-Based Development ist für moderne Produktteams oft besser.

Aber wenn du mit traditionellen Kunden arbeitest, ist der beste Workflow nicht immer der schnellste. Es ist der, der Zusagen sichtbar macht, bevor sie zu Problemen werden.