Trunk-basierte Entwicklung vs. GitFlow für wöchentliche Releases

Warum wöchentliches Shipping mit dem falschen Branching-Modell chaotisch wird

Wöchentliches Shipping klingt einfach – bis zu der Woche, in der ihr es verpasst. Der Build ist am Donnerstag "fast fertig", QA findet spät am Freitag Probleme, und der Montag wird zur Aufräumaktion statt zum sauberen Neubeginn.

Ein großer Treiber ist euer Branching-Modell. Es bestimmt, wann Änderungen zusammenkommen, wo Integration passiert und wie schnell ihr euch erholt, wenn etwas kaputtgeht. Wenn Integration bis zum Ende der Woche verschoben wird, bezahlt ihr das mit Merge-Konflikten, Überraschungsbugs und wackeligen Testumgebungen.

Wenn der Workflow gegen euch arbeitet, fühlt es sich meist so an:

• Merges dauern länger als die eigentliche Feature-Arbeit, die sie verursacht haben.
• QA testet die falsche Mischung aus Änderungen, weil Branches auseinanderdriften.
• Releases werden zur Verhandlung statt zur Routine.
• Hotfixes lösen Panik aus, weil niemand sicher ist, was noch mit ausgeliefert wird.
• Leute vertrauen QA nicht mehr und bitten um Ausnahmen.

Branching beeinflusst auch die Stabilität von QA. Wenn QA ständig zwischen halb integrierten Codepfaden hin- und herspringt, ist das Ziel in Bewegung. Selbst starke Tester können keine klaren Antworten geben, wenn das System unter Test sich alle paar Stunden ändert oder ein später Merge leise ersetzt, was gestern getestet wurde.

Deshalb vergleichen Teams oft trunk-basierte Entwicklung und GitFlow, wenn sie auf einen wöchentlichen Release-Rhythmus umstellen. Die sinnvolle Frage ist nicht, welche Methode populärer ist, sondern welche die Merge-Schmerzen reduziert, Releases vorhersehbar macht, Hotfixes sicher und schnell gestaltet und QA sinnvoll hält.

Nehmt ein kleines bis mittelgroßes Team an, ein gemeinsames Repo, CI bei jedem Push. Vielleicht liefert ihr eine Web-App und eine API. Oder ein Teil des Teams arbeitet visuell in einer Plattform wie AppMaster, verwaltet aber trotzdem generierten Code und Deployments wie jedes andere Produktteam.

Wenn euer aktueller Prozess große, end-of-week Merges erzeugt, wird eure wöchentliche Kadenz weiter ins Rutschen geraten. Wenn er kurze, häufige Integration fördert, werden wöchentliche Releases bald langweilig – und das im besten Sinne.

Trunk-basierte Entwicklung und GitFlow in einfachen Worten

Beide Ansätze sind Regeln dafür, wie ihr Branches benutzt, damit Arbeit von "in Arbeit" zu "ausgeliefert" gelangt, ohne Chaos. Der eigentliche Unterschied ist, wie viele längerlebige Branches ihr pflegt und wie lange Arbeit getrennt bleibt, bevor sie auf den Code der anderen trifft.

• Trunk-basiert hält fast alles nahe bei main.
• GitFlow hält getrennte Spuren für laufende Arbeit und Release-Stabilisierungen.

Trunk-basierte Entwicklung (einfach erklärt)

Trunk-basierte Entwicklung behandelt main (den Trunk) als Zentrum. Menschen arbeiten in kurzlebigen Branches (Stunden bis ein oder zwei Tage), mergen häufig zurück und halten main in einem auslieferbaren Zustand.

Ist etwas nicht fertig, macht ihr es entweder klein genug, um es schnell abzuschließen, oder ihr versteckt es hinter einem Feature-Flag, damit es sicher mitgeliefert werden kann, ohne sichtbar zu sein.

GitFlow (einfach erklärt)

GitFlow nutzt typischerweise einen längerlebigen develop-Branch, in den Features zuerst landen, plus Feature-Branches von develop. Kurz vor dem Release schneidet ihr einen release/*-Branch, um zu stabilisieren und zu testen. Bricht die Produktion, schneidet ihr einen hotfix/*-Branch (oft von main) und merged ihn zurück.

Dieses Modell optimiert Trennung: Laufende Arbeit kann in develop weitergehen, während der Release-Branch getestet und gepatcht wird.

Viel Schmerz kommt von Missverständnissen:

• Trunk-basiert als "keine Branches" zu sehen (es werden weiterhin Branches genutzt, sie sind nur kurzlebig).
• GitFlow zu nutzen, aber nie echte Release-Branches zu erstellen, sodass develop zur instabilen Staging-Fläche wird.
• Feature-Branches wochenlang leben zu lassen – das macht jedes Modell zum Merge-Problem.
• "Releasable" mit "alles ist fertig" zu verwechseln statt mit "sicher deploybar".

Merge-Reibung: Was sie wirklich verursacht

Merge-Konflikte entstehen meist aus zwei Quellen: Branches, die zu lange leben, und mehrere Leute, die ohne Koordination dieselben Bereiche ändern.

Der größte praktische Unterschied zwischen trunk-basiert und GitFlow ist, wie lange Arbeit getrennt bleibt, bevor sie auf andere trifft.

Bei trunk-basiertem Arbeiten landen Änderungen oft auf der Hauptlinie. Pull Requests sind kleiner, Diffs sind kleiner und Konflikte treten früher auf, während der Kontext noch klar ist. Konflikte passieren immer noch, aber sie sind meist leichter zu lösen, weil ihr ein paar Zeilen reconciliert und nicht zwei Wochen Drift. Der Preis ist Disziplin: Builds grün halten, Änderungen inkrementell halten und main wie das Produkt behandeln.

Bei GitFlow kann Feature-Arbeit länger liegen, ohne andere Entwickler täglich zu beeinflussen. Die Kosten zeigen sich später als größere Merge-Ereignisse: Feature → develop, develop → release/* und release/* → main. Jeder Merge ist ein größeres Zusammentreffen von Änderungen, daher sind Konflikte wahrscheinlicher und schwerer zu entwirren. Für wöchentliches Shipping landen diese großen Merges oft genau dann, wenn das Team testen möchte.

Die Code-Review-Last verschiebt sich ebenfalls. Trunk-basiert bedeutet meist mehr Reviews, aber jeder ist schneller zu überblicken. GitFlow hat oft weniger, aber schwerere Reviews, plus zusätzliche Review-Zeit bei Release-Merges, wenn alle müde sind.

Um Merge-Reibung in beiden Modellen zu reduzieren:

• Halte PRs klein und fokussiert (jeweils ein Ziel).
• Vereinbart Ownership für riskante Bereiche (Migrationen, geteilte Konfiguration, Core-UI).
• Zieht täglich Upstream-Änderungen, damit ihr nicht driftet.
• Wenn eine Datei konstant "heiß" ist, arbeitet paarweise daran statt parallel und kollidierend.

Wenn Konflikte ständig vorkommen, ist das meist ein Zeichen, dass ihr zu spät integriert – nicht, dass Git das Problem ist.

Release-Vorhersehbarkeit für eine wöchentliche Kadenz

Vorhersehbarkeit bedeutet drei Dinge: Ihr wisst, wann das Release rausgeht, ihr wisst, was drin ist, und ihr wisst, welche Checks vor dem Shipping passieren müssen. Teams verpassen wöchentliche Releases oft, weil Scope-Entscheidungen mit Last-Minute-Fixing vermischt werden.

Bei trunk-basiertem Arbeiten bleiben wöchentliche Releases vorhersehbar, wenn main grün bleibt. Ihr merged kleine Änderungen häufig und kontrolliert den Scope mit Feature-Flags statt mit langlebigen Branches. So bleibt der Wochenzug in Fahrt, auch wenn ein Feature nicht fertig ist. Der Code kann landen, aber das sichtbare Verhalten bleibt aus, bis es bereit ist.

Quality-Gates sind oft einfacher, weil es einen Ort zur Validierung gibt:

• Automatisierte Tests müssen auf main bestehen.
• QA testet einen stabilen Kandidaten-Build, nicht das, was gerade vor einer Stunde gelandet ist.
• Rollout- und Rollback-Schritte sind dokumentiert.
• Es gibt eine klare Release-Cutoff-Zeit (auch wenn Commits weiter landen können).

Bei GitFlow kommt Vorhersehbarkeit durch den Release-Branch, der wie eine Freeze-Zone wirkt. Ihr legt einen Cutoff fest, erstellt release/* und erlaubt nur Änderungen, die zum Shippen nötig sind. Diese Grenze hilft, schafft aber Koordinationsaufwand, weil Fixes oft an mehreren Stellen angewendet werden müssen (release und develop).

Unfertige Arbeit wird unterschiedlich gehandhabt:

• Trunk-basiert: Merge sichere Teile und haltet den Rest hinter Flags.
• GitFlow: Haltet Unfertiges in develop und schließt es vom Release-Branch aus.

Beispiel: Wenn Checkout-Verbesserungen bis Mittwoch halb fertig sind, kann trunk-basiert sichere Refactorings mergen und die neue UI verborgen halten. GitFlow lässt es meist in develop, shipped ohne sie und beendet es für das nächste wöchentliche Release.

Hotfix-Flow: Der schnellste sichere Weg zur Produktion

Ein Hotfix ist keine normale Arbeit. Er braucht Geschwindigkeit, geringes Risiko und einen Weg, die Änderung dorthin zu bringen, wo das Team arbeitet, damit ihr denselben Bug nicht zweimal behebt.

Startet mit einer Frage: Welcher Code läuft genau in Produktion gerade? Wenn ihr das nicht in Sekunden beantworten könnt, werden Hotfixes zur Ratesache.

Hotfixes bei trunk-basierter Entwicklung

Hotfixes können sich einfacher anfühlen, weil main als Wahrheit angesehen wird.

Ein üblicher Ablauf:

• Erstelle einen kurzlebigen Branch vom Produktions-Commit (oft main).
• Mach die kleinstmögliche Änderung (füge wenn möglich einen Test hinzu).
• Merge schnell zurück nach main.
• Deploye von main und tagge das Release.

Weil das Team häufig in main integriert, wird der Hotfix automatisch Teil des nächsten wöchentlichen Releases. Das größte Risiko ist, die Regel "main ist releasable" zu verletzen, indem halbfertige Arbeit in main bleibt. Feature-Flags helfen, aber haltet sie standardmäßig aus und verifiziert den Hotfix ohne Aktivierung anderer Features.

Hotfixes bei GitFlow

Bei GitFlow starten Hotfixes meist von main (Produktion) und müssen zurück in develop gemergt werden, damit der Fix nicht verloren geht.

Ein sicherer Ablauf:

• Branch hotfix/* von main am Produktionstag.
• Fixen und releasen (entweder vom Hotfix-Branch oder nachdem ihr nach main gemerged habt).
• Merge den Hotfix in main und auch in develop.
• Falls ein release/* existiert, auch dort hinein mergen.

Der häufigste Fehler ist, einen dieser Merges zu vergessen. Eine Woche später ist der Bug "wieder da", weil develop nie den Patch bekam.

Eine einfache Regel verhindert das meiste: Ein Hotfix ist erst abgeschlossen, wenn er in jeden längerlebigen Branch gemergt ist, der wieder liefern wird.

Wie QA-Umgebungen stabil bleiben (ohne das Team zu blockieren)

Wöchentliches Shipping scheitert, wenn "QA" bedeutet "was gerade deployed ist." Gebt euren Umgebungen Namen und eine Aufgabe: dev für schnelles Feedback, QA für Teamtests, staging für Release-Checks, prod für Kunden. Wenn ihr den Zweck einer Umgebung nicht in einem Satz erklären könnt, wird sie falsch genutzt.

Regeln, die bewegliche Ziele verhindern

Stabile QA hängt weniger vom Branching-Modell ab und mehr davon, was ihr deployt.

Bei trunk-basiertem Arbeiten deployed nicht zufällige Commits in QA. Nutzt einen gepinnten Kandidaten (getaggter Build, Build-Nummer oder kurzlebiger Release-Candidate-Branch), der jedes Mal dieselben Checks besteht. QA bekommt so etwas Fixiertes zum Testen, während Entwicklung auf main weitergeht.

Bei GitFlow folgt QA üblicherweise dem Release-Branch. Die Falle ist, dass der Release-Branch sich weiter ändert, nachdem QA angefangen hat. Sobald QA beginnt, behandelt den Release-Branch wie einen Vertrag: Nur genehmigte Fixes werden akzeptiert und nur über einen klaren Prozess.

Ein kleiner Regelkatalog macht beide Ansätze vorhersehbar:

• Deploye in QA nur aus erfolgreichen Builds.
• Pinnt die deployte Version (Tag, Build-Nummer oder Release-Branch-Head) und kündigt sie an.
• Erlaubt in QA nur Bugfixes, keine neuen Features.
• Setzt Testdaten regelmäßig zurück und dokumentiert, was gelöscht wird.
• Haltet Konfiguration als Code (Variablen und Templates), um Drift zu reduzieren.

Wenn euer Team AppMaster für Teile des Builds nutzt, gilt dasselbe Prinzip: regeneriert und deployed einen konkreten Build für QA, nicht eine ständig wechselnde Menge an Änderungen.

Wenn mehrere Teams QA teilen

Eine gemeinsame QA-Umgebung wird zum Engpass, wenn zwei Teams unterschiedliche Versionen brauchen. Wenn ihr euch keine separaten QA-Umgebungen leisten könnt, führt eine leichte Reservierungsregel ein: Ein Team besitzt QA für ein Zeitfenster, alle anderen nutzen dev oder staging. Feature-Flags helfen ebenfalls, weil unfertige Arbeit deployed werden kann, ohne für Tester sichtbar zu sein.

Beispiel: Team A validiert den wöchentlichen Release-Kandidaten, also bleibt QA bis zur Abnahme auf Build 1842 gepinnt. Team B kann weiter Fixes mergen, aber diese Änderungen warten auf den nächsten Kandidaten anstatt das, was QA testet, mitten im Zyklus zu verändern.

Schritt für Schritt: Wählt einen Workflow, dem euer Team jede Woche folgen kann

Schreibt auf, was "wöchentliches Shipping" für euch bedeutet. Wählt einen Release-Tag und eine Uhrzeit, entscheidet, welches Risiko akzeptabel ist (z. B. "keine bekannten P1-Bugs") und notiert Teamgröße und Zeitzonen. Das verhindert, dass Branch-Debatten zu Prioritätsstreitigkeiten werden.

Wählt ein Basis-Modell und bleibt einen Monat dabei. Mischt nicht am ersten Tag verschiedene Modelle. Mischen schafft meist nur mehr Regeln ohne weniger Überraschungen.

Ein einfacher wöchentlicher Workflow, den ihr anpassen könnt:

• Haltet Branch-Lebenszeiten kurz (Stunden bis 1–2 Tage) und merged mindestens täglich.
• Fügt Sicherheitsleitplanken hinzu: schnelles CI, kurze erforderliche Reviews und eine kleine Menge automatisierter Tests, die echte Breakages fangen.
• Entscheidet, wie ihr Scope kontrolliert: Feature-Flags, kurzlebiger Release-Branch gegen Ende der Woche oder Tags für den exakten Release-Commit.
• Definiert Hotfix-Schritte: Wer einen Hotfix auslösen darf, welche Checks nötig sind und wie der Fix zurück in die Hauptlinie kommt.
• Haltet QA stabil: Entscheidet, was QA verfolgt (Release-Branch oder gepinnter Kandidat) und ändert das nicht mitten im Test, außer ihr startet den Zyklus neu.

Schreibt den minimalen Workflow auf eine Seite. Er sollte so kurz sein, dass ein neues Teammitglied ihn ohne Meeting befolgen kann. Das ist besonders wichtig, wenn ein Teil des Teams visuell arbeitet (z. B. in AppMaster) und ein Teil im Code, weil Übergaben fehlschlagen, wenn Regeln nur im Kopf eines Einzelnen leben.

Beispiel: Ein realistisches wöchentliches Release in beiden Modellen

Stellt euch ein 6-köpfiges Produktteam vor, das jeden Freitag ausliefert. Zwei QA-Tester teilen eine Staging-Umgebung; ist Staging instabil, stoppt das Testing für alle.

Eine volle Woche mit GitFlow

Montag: Drei Entwickler schließen Features ab und öffnen Pull Requests in develop. QA beginnt mit Tests auf Staging, gebaut aus develop.

Mittwoch: Das Team schneidet release/1.8, um den Freitag zu schützen. Neue Arbeit landet weiter in develop, aber QA fokussiert nun den Release-Build.

Donnerstag Nachmittag: Ein später Bug taucht auf. Der Fix landet zuerst in release/1.8, damit QA schnell retesten kann. Danach merged jemand den Fix zurück in develop – hier passieren oft Fehler.

Ein typischer Rhythmus:

• Mo–Di: Features mergen in develop, Staging ändert sich oft.
• Mi: release/1.8 erstellen, Staging wechselt zu Release-Builds.
• Do: Bugfix in release/1.8, dann Merge zurück nach develop.
• Fr: Merge release/1.8 nach main, taggen und deployen.

Dieselbe Woche mit trunk-basierter Entwicklung

Die Woche ist um kleine, häufige Merges in main herum organisiert. Features liegen hinter Flags, sodass unvollständige Arbeit gemerged werden kann, ohne Nutzer zu beeinflussen.

Mo–Do: Entwickler mergen kleine Änderungen täglich. QA testet einen gepinnten Kandidaten-Build.

Dienstag: Ein Produktionsproblem taucht auf. Der Hotfix ist ein kurzer Branch von main, wird nach Review sofort gemerged und dann promoted. Da main die Quelle der Wahrheit ist, gibt es keinen zusätzlichen Back-Merge-Schritt.

In beiden Fällen braucht das Team klare Promotingsregeln:

• Staging läuft mit dem letzten gepinnten Kandidaten-Build, nicht mit jedem Commit.
• QA fordert einen neuen Kandidaten an, wenn bereit – nicht automatisch.
• Nur Fixes für das Freitags-Release dürfen den Kandidaten ändern.
• Alles andere bleibt hinter Flags oder außerhalb des Kandidaten.

Häufige Fehler, die Chaos und instabile QA erzeugen

Die meisten Teams scheitern nicht, weil sie das "falsche" Modell gewählt haben. Sie scheitern, weil die täglichen Gewohnheiten nicht zum Modell passen, sodass QA laut wird und Releases zufällig wirken.

Ein häufiger Fehler ist, Branches mehrere Tage liegen zu lassen, weil "es ist noch nicht fertig." Der Code driftet von main weg, Konflikte sammeln sich und QA testet eine Mischung aus alt und neu, die niemand reproduzieren kann.

Ein anderer ist, GitFlow ohne echten Freeze zu benutzen. Ein Release-Branch soll stabilisieren, aber Teams schleusen ständig noch "eine Kleinigkeit" hinein. Dann wird der Release-Branch zur zweiten Hauptlinie und niemand weiß, wofür QA eigentlich abnimmt.

QA wird auch instabil, wenn sie als Ablage für halb fertige Builds missbraucht wird. Wenn jeder Commit ohne Regeln in QA landet, jagen Tester beweglichen Zielen hinterher statt ein Release zu validieren.

Die Fehler, die den meisten Aufwand erzeugen:

• Lang lebende Feature-Branches, die spät mergen und unzusammenhängende Arbeit brechen.
• Release-Branches, die weiterhin neue Features annehmen.
• Kein klarer Promotionspfad, sodass der getestete Build nicht der ist, der ausliefert.
• Hotfixes, die in Eile gemacht und dann nicht überall zurückgemerged werden.
• Umgebungen ohne Owner, Zweck oder Reset-Plan.

Haltet ein Regelwerk, das jeder wiederholen kann:

• QA testet nur einen gepinnten Kandidaten.
• Dasselbe Artefakt wird von QA nach Produktion promoted.
• Jede Umgebung hat einen Owner und eine Reset-Frequenz.
• Hotfixes fließen am selben Tag zurück in die Hauptlinie.

Kurze Checkliste für wöchentliches Shipping ohne Überraschungen

Wöchentliches Shipping funktioniert, wenn euer Team einige langweilige Fragen sicher beantworten kann. Antwortet ihr auf zwei oder mehr mit "nein", erwartet späte Fixes und QA-Whiplash.

• Gibt es einen Branch, den ihr heute sicher deployen könnt? Er sollte bauen, Smoke-Tests bestehen und keine halb angekoppelten Änderungen enthalten.
• Bleiben Pull Requests klein und landen innerhalb ein bis zwei Tagen? Lang lebende PRs bedeuten meist stale Feedback und größere Konflikte.
• Testet QA einen festen Build, nicht ein bewegliches Ziel? QA sollte eine spezifische Build-Nummer oder einen Release-Kandidaten validieren.
• Könnt ihr unfertige Arbeit ohne Drama aus dem Release halten? Feature-Flags, Config-Toggles oder klare Scope-Cut-Regeln helfen.
• Kann jemand einen Hotfix und Rollback ohne Raten durchführen? Ein kurzes Runbook schlägt tribal knowledge.

Wenn ihr ein messbares Ziel wollt: Pinnt QA an einen Release-Kandidaten und haltet diesen Kandidaten unverändert, außer für gezielte Fixes.

Nächste Schritte: Wählt eine Änderung, die ihr nächste Woche ausprobiert

Wenn euer Team in der Debatte trunk vs GitFlow steckt, überarbeitet nicht sofort alles. Wählt das eine Problem, das am meisten Zeit kostet, und macht ein kleines Experiment für das nächste Release.

Wenn Merge-Konflikte das größte Problem sind, verkürzt Branch-Lebenszeiten sofort. Ziel: tägliches Landen (oder jeden zweiten Tag), nutzt Feature-Flags bei Bedarf.

Wenn QA-Instabilität das größte Problem ist, pinnt zuerst, was QA testet, und definiert einen einfachen Promotionsschritt.

Ein leichtes Pilotprojekt:

• Wählt ein Repo und ein Team.
• Setzt ein Branch-Alter-Limit (z. B. kein Branch älter als 2 Tage).
• Pinnt QA an einen Build und ändert ihn nur durch explizite Promotion.
• Messt drei Werte: Merge-Auflösungszeit, QA-Nacharbeit-Stunden und Hotfix-Time-to-Production.
• Evaluieren nach 2–4 Wochen und passt an.

Wenn ihr Release-Druck für interne Tools oder Kundenportale reduzieren wollt, kann eine No-Code-Plattform wie AppMaster (appmaster.io) helfen, indem sie produktionsbereiten Backend-, Web- und nativen Mobile-Code aus visueller Gestaltung generiert. Sie profitiert trotzdem von denselben Gewohnheiten: kleine Änderungen, gepinnte QA-Kandidaten und ein klarer Promotionspfad.