Inhaltsverzeichnis

Von Subversion zu Git: Strukturierte Migration sicherheitsrelevanter Projekte #

Einleitung #

Viele Unternehmen und Teams im sicherheitskritischen Umfeld arbeiten historisch bedingt mit Apache Subversion (SVN). SVN bietet durch sein zentrales Repositorium und die Möglichkeit, Teilbereiche selektiv auszuchecken, eine Projektorganisation, die gut mit klassischen Modellen wie dem V-Modell XT harmoniert.

Doch die IT-Landschaft verändert sich: Git hat sich als moderner De-facto-Standard in der Softwareentwicklung etabliert. Dezentrale Arbeitsweise, leistungsfähige Branching-Modelle und weitreichende Toolunterstützung sprechen für einen Wechsel – auch im regulierten Umfeld. Allerdings bringt Git strukturelle Unterschiede mit, die bei einem Umstieg beachtet werden müssen, um etablierte Arbeitsweisen nicht zu verlieren.

Dieser Beitrag beleuchtet die zentralen Unterschiede zwischen SVN und Git hinsichtlich der Projektstrukturierung, stellt geeignete Alternativen zur Pfadorientierung in Git vor und zeigt, wie eine Migration strukturiert und nachhaltig erfolgen kann.

Projektstrukturierung in SVN und Git #

Subversion (SVN) #

Subversion organisiert alle Inhalte in einem zentralen Repositorium. Eine typische Struktur kann wie folgt aussehen:

/project/
  /trunk/
    /src/
    /test/
    /docs/
    /management/
    /qm/

Der große Vorteil: Es können gezielt einzelne Verzeichnisse ausgecheckt werden, z.B. nur test oder qm. So können Rollen und Verantwortlichkeiten organisatorisch sauber abgebildet werden. In sicherheitskritischen Umfeldern ist dies nützlich, um z.B. die Trennung von Entwicklung, Verifikation und Validierung zu unterstützen.

Allerdings führt dies bei unklaren Regeln schnell zu Wildwuchs: parallele Trunks, isolierte Teilbereiche ohne Zusammenhang, kaum durchgängige Releases oder Verlinkungen auf Dateiebene (z.B. Word-Dokumente). Dies erschwert Reproduzierbarkeit und Wartbarkeit.

Git #

Git setzt auf ein dezentrales Modell. Jeder Klon enthält die komplette Historie. Es gibt keine native Möglichkeit, nur Teilbereiche des Repos zu klonen oder „teilweise zu arbeiten“. Das bedeutet:

Ein Git-Monorepo lädt immer die gesamte Projektstruktur.
Modularisierung erfolgt typischerweise über mehrere Repositories, die logisch miteinander verbunden sind.

Dies erfordert ein Umdenken in der Organisation: Struktur, Ownership, Tooling und Release-Management müssen klar definiert sein.

Mögliche Git-Strategien zur Strukturierung #

Um etablierte Arbeitsweisen aus SVN mit Git nachzubilden – insbesondere die Trennung nach V-Modell-Komponenten (z.B. Entwicklung, Test, QS) – bieten sich verschiedene Ansätze an:

1. Monorepo mit klarer Projektstruktur #

Ein einziges Git-Repository enthält alle Projektbestandteile:

/project/
  /development/
  /test/
  /qm/
  /docs/
  /management/

Vorteile:

Einfache Navigation
Einheitliches Versioning (Branch/Tag gilt für alles)

Nachteile:

Kein selektives Arbeiten
Git-Historie kann schnell sehr groß werden
Zugriffssteuerung nur grob möglich

2. Submodule #

Jeder Bereich (z.B. Test, QM) ist ein eigenes Repository. Ein zentrales Meta-Repository bindet diese als Git-Submodule ein:

/project-meta/
  development/  → Submodule
  test/         → Submodule
  qm/           → Submodule

Vorteile:

Bereichsweise Verantwortlichkeiten möglich
Getrennte Historien

Nachteile:

Komplexes Handling (git submodule update etc.)
CI/CD muss Submodule korrekt behandeln
Fehleranfällig bei unerfahrenen Entwicklern

3. Subtree-Integration #

Ein Subprojekt wird vollständig in ein Haupt-Repo integriert, aber seine Herkunft bleibt nachvollziehbar.

Beispiel:

git subtree add --prefix=test https://git.example.com/test.git main

Vorteile:

Einfache Handhabung, keine Submodule
Komplette Historie bleibt erhalten
Kein separates Submodule-Management

Nachteile:

Push zurück zum Ursprungsrepo ist möglich, aber technisch aufwendiger
Zusammenführen (Merge) bei getrennter Weiterentwicklung ist nicht trivial

4. Multi-Repo mit Meta-Integration #

Jede V-Modell-Komponente erhält ein eigenes Git-Repository:

project-dev.git
project-test.git
project-qm.git
project-docs.git
project-management.git

Ein zentrales Meta-Repository (rein organisatorisch) dokumentiert:

Versionsstände per Tag
Release-Matrix
CI/CD-Workflows

Vorteile:

Klare Trennung von Verantwortlichkeiten
Ideale Skalierbarkeit bei großen Projekten
Zugriffskontrolle, Tools und Pipelines lassen sich optimal aufteilen

Nachteile:

Erfordert Disziplin bei der Versionspflege
Tooling muss angepasst werden (Build-Integration, Release-Matrix)

Hands-On: Subtree-Ansatz als Einstieg (Beispiel 3) #

Der Subtree-Ansatz ist ein guter Startpunkt, wenn man von einem monolithischen SVN-Projekt migriert und zunächst die Vorteile von Git nutzen möchte, ohne gleich auf eine vollständige Multi-Repo-Struktur zu wechseln.

Vorbereitung #

Die zu integrierenden Teilprojekte (z.B. test.git, qm.git) liegen bereits als Git-Repositories vor
Das Hauptprojekt (project.git) soll diese integrieren

Beispiel: Integration eines Test-Repositories #

git clone https://git.example.com/project.git
cd project
git subtree add --prefix=test https://git.example.com/test.git main

Nun liegt das Testprojekt im Verzeichnis test/ inklusive aller Historie.

Aktualisierung bei Änderungen im Upstream-Repo #

git subtree pull --prefix=test https://git.example.com/test.git main

Optional: Weitergabe von Änderungen #

git subtree push --prefix=test https://git.example.com/test.git main

Weiterführender Ansatz: Vollständige Multi-Repo-Strategie (Beispiel 4) #

Wenn das Projekt wächst oder langfristig wartbar sein muss, ist eine saubere Aufteilung über mehrere Repositories ratsam.

Tooling und Infrastruktur können dabei unterstützen:

GitLab/Gitea Gruppenstruktur
Versionsmanagement per Git-Tags
CI/CD-Pipelines für jedes Teilprojekt
Dokumentierte Release-Matrix

Die Nutzung des Subtree-Ansatzes kann dabei als Übergang oder Pilotprojekt dienen.

Fazit #

Ein Wechsel von SVN zu Git ist im sicherheitskritischen Umfeld möglich – und sinnvoll, sofern die Projektstruktur mit Augenmaß geplant wird. Die Wahl des passenden Strukturierungsansatzes hängt von Teamgröße, Prozessanforderungen und Tooling ab.

Insbesondere durch die Kombination aus Subtrees als sanfte Migration und Multi-Repo-Strukturen für langfristige Wartbarkeit lässt sich eine Git-basierte Projektwelt aufbauen, die sowohl den Anforderungen des V-Modells als auch moderner Entwicklung gerecht wird.