Branching-Strategien für Long-Term-Support und CRA-Compliance

Der Cyber Resilience Act fordert Security-Updates über Jahre hinweg, unabhängig von Feature-Releases. Für Unternehmen, die Maschinen oder HMI-Software mit 15 Jahren oder mehr Support ausliefern, bedeutet das eine enorme Herausforderung. Während die Feature-Entwicklung weitergeht, müssen parallel ältere Versionen mit Sicherheitspatches versorgt werden. Welche Branching-Strategie macht das handhabbar?

Dabei ist das Prinzip unabhängig vom Tooling: Im Artikel nutze ich Git-Begriffe (weil Git heute Standard ist), aber die Idee, Versionen eindeutig zu markieren und nur bei Bedarf zu branchen, lässt sich auch auf andere Versionskontrollsysteme übertragen.

Ein typisches Szenario verdeutlicht die Dimension: Du lieferst über 15 Jahre hinweg regelmäßig Releases aus, z.B. jährlich oder halbjährlich. Allein dadurch existieren schnell 15 bis 30 Produktiv-Versionen, die im Support-Fall parallel gepatcht werden müssen. Hinzu kommen Versionen mit kundenspezfischen Anpassungen. Die Frage ist daher nicht mehr, ob du eine Branching-Strategie brauchst, sondern welche. Dieser Artikel beleuchtet die strategischen Entscheidungen. Welche Strategie passt wann? Und wie bringst du Fixes sauber in mehrere Versionen?

Der Cyber Resilience Act und Security-Update-Pflicht

Der Cyber Resilience Act (CRA) der EU verpflichtet Hersteller, während des gesamten Produktlebenszyklus Security-Updates bereitzustellen. Bei industriellen Systemen wie Maschinen, technischen Geräten oder Steuerungsanlagen bedeutet das oft Support-Verpflichtungen von 10 bis 20 Jahren. Die Pflichten für Hersteller sind klar definiert: Sicherheitslücken müssen innerhalb kurzer Fristen geschlossen werden.

Eine weitere Forderung des CRA ist die Trennung von Security-Patches und Feature-Updates. Ein Maschinenbetreiber, der seine Anlage seit zehn Jahren im Einsatz hat, möchte keine neuen Features mit ungetesteten Änderungen, sondern ausschließlich kritische Sicherheitsfixes. Gleichzeitig entwickelt dein Team neue Versionen mit erweiterten Funktionen für aktuelle Kunden. Diese beiden Entwicklungsstränge müssen parallel existieren, ohne sich gegenseitig zu blockieren.

Branching-Strategien im Vergleich: Git Flow vs. GitHub Flow

Die Wahl der richtigen Branching-Strategie hängt von mehreren Faktoren ab: Wie oft integrierst du Code? Wie oft lieferst du neue Versionen aus? Wie viele alte Versionen müssen parallel gepflegt werden? Die zwei etablierten Ansätze haben jeweils unterschiedliche Stärken.

Es gibt heute zwei sehr beliebte Modelle zum Umgang mit Branches: Git Flow und GitHub Flow.

Git Flow ist ein bewährtes, bereits seit 2010 etabliertes Modell mit klaren Rollen für verschiedene Branch-Typen. Der develop-Branch dient der aktiven Entwicklung, release-Branches stabilisieren kommende Versionen, und hotfix-Branches ermöglichen schnelle Produktionsfixes. Die Trennung zwischen Feature-Entwicklung und Releases ist explizit und nachvollziehbar.

GitHub Flow oder auch Trunk-Based Development beschreiben im Kern die gleiche Strategie: einen minimalistischen Ansatz mit einem main-Branch (Trunk), in den alle Entwickler:innen über sehr kurzlebige Feature-Branches integrieren. Die hohe Integrationsfrequenz reduziert Merge-Konflikte drastisch und fördert kontinuierliches Refactoring. Auch Hotfixes sind hier kurzlebige Branches.

In beiden Modellen helfen Regeln für die Namensgebung wie z.B. Conventional Branch bei der Organisation, Navigation und Verständlichkeit der Branches.

Beiden Modellen liegt zudem die gleiche Idee zugrunde: Es gibt nur einen langlebigen Branch (main) und einen kontinuierlichen Fluss von Releases innerhalb dieses Branches. Beide Modelle berücksichtigen nicht, dass auch ältere Versionen mit z.B. Security Patches gepflegt werden müssen. Mehrere parallele Produktiv-Versionen und somit mehrere langlebgige Branches sind nicht vorgesehen. Branch-for-Release ist hier die Lösung, weil hierdurch die Release-Branches, im Gegensatz zu GitFlow, langlebig werden und über den gesamten Supportzeitraum existieren.

Release Branches: Die Lösung für Long-Term-Support

Für vielzählige parallele Versionen ist ein Modell nötig, das Skalierbarkeit mit Wartbarkeit vereint. Release Branches sind die bewährte Antwort. Das Konzept ist einfach: Für jede veröffentlichte Version existiert bei Bedarf ein eigener Branch. Der main-Branch repräsentiert die aktive Entwicklung, alte Versionen leben in ihren Release Branches weiter. Solange noch keine Patches für ein Release notwendig sind, kann zur Kennzeichnung auf Tags oder Labels zurückgegriffen werden. Dies ist besonderes relevant bei Versionkontrollsystemen, bei denen Branches keine leichtgewichtigen Elemente sind, sondern eher Kopien des Stands darstellen. Dies ist z.B. bei TFVC, CVS oder Visual Source Safe (ja, da gibt es noch immer Instanzen in freier Wildbahn) der Fall.

Der Workflow ist klar strukturiert. Wenn eine neue Version bereit ist, erstellst du ein Tag für das Release. Und später, wenn Du einen Fix liefern musst, erzeugst Du den Branch und lässt den Fix dort einfließen.

# Release vorbereiten und taggen
git checkout main
git pull
git tag -a v2.5.0 -m "Release 2.5.0"
git push origin v2.5.0

# Kein Branch nötig, solange keine Patches erforderlich sind

# Monate später: Security-Patch nötig
git checkout -b release/v2.5 v2.5.0
# Jetzt existiert der Branch und kann gepatcht werden

Bereitstellen von Patches

Wenn eine Sicherheitslücke auftritt, musst du zuerst klären, welche Versionen überhaupt betroffen sind (typischerweise: alle noch unterstützten Versionen, die die betroffene Komponente enthalten).

Danach gilt: Der Fix muss in jede betroffene Version. Und das so, dass er sowohl in main (für die Zukunft) als auch in den betroffenen Release Branches (für die Wartung) landet.

Oft ist der einfachste Weg: Den Fix in einem Branch implementieren, in main integrieren und dann per Cherry-Pick in die Release Branches portieren. Wenn ein Cherry-Pick wegen Divergenz nicht sauber funktioniert, ist ein eigener Backport-Commit auf dem Release Branch völlig normal. Wichtig ist nur, dass du den Fix in beiden Richtungen konsistent hältst: Was du auf einem Release Branch änderst, muss (sofern sinnvoll) auch zurück nach main.

# Security-Fix auf main entwickeln
git checkout main
git commit -m "Security: Fix CVE-2026-12345"
git push

# Fix auf alte Versionen portieren
# Falls Branch existiert:
git checkout release/v2.5
git cherry-pick <commit-hash>
git tag v2.5.1
git push origin release/v2.5 --tags

# Falls noch kein Branch existiert, vom Tag aus erstellen:
git checkout -b release/v2.4 v2.4.0
git cherry-pick <commit-hash>
git tag v2.4.1
git push origin release/v2.4 --tags

Die Skalierbarkeit entsteht durch klare Regeln und das Lazy-Branch-Prinzip. Alte Branches werden nicht gelöscht, aber typischerweise schreibgeschützt, sobald der Support endet. Tags bleiben als historische Marker erhalten, auch wenn nie ein Branch dafür erstellt wurde. Das Branch-Organization-Modell von Azure DevOps unterstützt diese Struktur mit Branch Policies und geschützten Branches, auch wenn sie sich gegen Tags ausspricht. Martin Fowlers Release Branch Pattern beschreibt die theoretischen Grundlagen dieser Strategie.

Noch ein Wort zu den Werkzeugen: Wenn du heute die Wahl hast, ist Git in der Praxis meist die robusteste Basis für Long-Term-Support, weil eine Git-basierte Toolchain mit geringem Overhead für Versionen (Tags), leichtgewichtigen Branches, guter Automatisierbarkeit (CI/CD) und sauberer Nachvollziehbarkeit Reviews und Audits deutlich besser und robuster unterstützt. Darüber hinaus ist nicht nur das Versionskontrollsystem wichtig, sondern auch die Umgebung: Nutze Git in einer Plattform, die Pull Requests komfortabel unterstützt und mittels Branch Policies und Build-Validierung das saubere und konsistente Ausliefern unterstützt. Typische Optionen sind Azure DevOps Repos, GitHub oder GitLab.

Fazit

Wenn du wenige Versionen parallel pflegst und geplante Releases hast, kann GitHub Flow und Trunk-Based Development ausreichend sein. Sobald du viele Versionen über Jahre parallel patchen musst, führt an Release Branches (bei Bedarf) plus klaren Release-Tags kaum ein Weg vorbei.

Wie gehst du mit Long-Term-Support und parallelen Versionen um? Schau gerne bei uns auf LinkedIn vorbei und diskutiere mit.