Warum jetzt noch migrieren?
Subversion funktioniert. Es ist stabil, ausgereift und hat in vielen Unternehmen jahrzehntelang zuverlässig seinen Dienst getan. Trotzdem führt für die meisten Teams heute kein Weg an Git vorbei. Nicht weil SVN schlecht wäre, sondern weil das gesamte Ökosystem -- CI/CD-Tools, Code-Review-Plattformen, Entwickler-Workflows -- auf Git ausgerichtet ist.
Neue Entwickler bringen Git-Kenntnisse mit, nicht SVN-Kenntnisse. GitLab, GitHub und Azure DevOps setzen Git voraus. Moderne CI/CD-Pipelines sind für Git-basierte Workflows optimiert. Je länger eine Organisation wartet, desto grösser wird die Kluft zwischen den internen Prozessen und dem, was der Markt als Standard betrachtet.
Die Migration planen
Historie: Alles oder selektiv?
Die erste große Entscheidung: Soll die gesamte SVN-Historie nach Git übernommen werden? Bei einem Repository mit 15 Jahren Geschichte und 50.000 Commits kann das Tage dauern und ein Git-Repository erzeugen, das unnötig groß ist.
Unsere Empfehlung: Übernehmen Sie die Historie der letzten zwei bis drei Jahre. Ältere Commits sind in der Praxis selten relevant, und das SVN-Repository bleibt als Archiv erhalten. Für Teams, die aus regulatorischen Gründen die vollständige Historie benötigen, ist die vollständige Migration natürlich möglich -- sie dauert nur länger.
Branch-Modell überdenken
SVN-Branches und Git-Branches sind fundamental verschieden. In SVN ist ein Branch eine Verzeichniskopie, in Git ein leichtgewichtiger Pointer. Das ändert die Art, wie Teams mit Branches arbeiten:
- SVN-Trunk wird typischerweise zum Git-main-Branch
- SVN-Release-Branches werden zu Git-Branches (oder Tags für abgeschlossene Releases)
- SVN-Feature-Branches werden oft nicht migriert -- sie sind in SVN meistens langlebig und in Git besser als kurzlebige Branches mit Merge Requests abgebildet
Author-Mapping
SVN verwendet Benutzernamen, Git verwendet Name und E-Mail-Adresse. Vor der Migration müssen Sie ein Author-Mapping erstellen:
jdoe = Jane Doe <jane.doe@company.com>
mmueller = Max Mueller <max.mueller@company.com>
Ohne dieses Mapping erscheinen die SVN-Benutzernamen als Autoren in der Git-Historie -- nicht falsch, aber unschön und für Tools wie GitLab nicht optimal.
Die technische Migration
Das bewäahrte Werkzeug für die Migration ist git svn. Der grundlegende Ablauf:
# SVN-Repository klonen (kann bei großer Historie Stunden dauern)
git svn clone --stdlayout --authors-file=authors.txt \
https://svn.company.com/repos/project project-git
cd project-git
# SVN-Remote-Referenzen in echte Git-Branches umwandeln
git for-each-ref refs/remotes/origin --format='%(refname)' | while read ref; do
branch=$(echo "$ref" | sed 's|refs/remotes/origin/||')
git branch "$branch" "$ref"
done
# Tags konvertieren
git for-each-ref refs/remotes/origin/tags --format='%(refname)' | while read ref; do
tag=$(echo "$ref" | sed 's|refs/remotes/origin/tags/||')
git tag "$tag" "$ref"
done
# Remote setzen und pushen
git remote add origin git@gitlab.company.com:group/project.git
git push --all origin
git push --tags origin
Für komplexere Szenarien -- etwa SVN-Repositories mit nicht-standardmäßigem Layout, svn:externals oder große Binärdateien -- gibt es spezialisierte Tools wie SubGit oder svn2git, die den Prozess vereinfachen.
Große Binärdateien behandeln
SVN kommt mit großen Binärdateien gut zurecht. Git nicht -- jede Version einer Binärdatei wird vollständig in der Historie gespeichert. Wenn Ihr SVN-Repository große Binärdateien enthält (CAD-Daten, Firmware-Images, Bibliotheken), sollten Sie diese entweder:
- Vor der Migration entfernen und in einem Artefakt-Repository (Nexus, Artifactory) ablegen
- Git LFS nutzen, um große Dateien außerhalb des Git-Repositorys zu speichern
Das Team mitnehmen
Die technische Migration ist oft der einfachere Teil. Der grössere Aufwand liegt darin, das Team auf Git umzustellen. SVN-Gewohnheiten -- zentrales Commit-Modell, seltene Branches, kein lokaler Commit -- müssen durch Git-Workflows ersetzt werden.
Planen Sie ausreichend Zeit für Schulungen ein. Ein Team, das Git nur oberflächlich versteht, wird frustriert sein und Fehler machen, die im schlimmsten Fall zu Datenverlust führen. Besonders die Konzepte Staging Area, lokale vs. Remote-Branches und Merge vs. Rebase verdienen besondere Aufmerksamkeit.
Fazit
Die SVN-zu-Git-Migration ist ein Projekt, kein Wochenende. Planen Sie vier bis sechs Wochen für ein mittelgroßes Team ein -- inklusive Vorbereitung, technischer Migration, Schulung und Parallelbetrieb. Der Aufwand lohnt sich: Danach arbeitet das Team mit einem Versionskontrollsystem, das zum modernen Entwicklungs-Ökosystem passt.
Unser Git und GitLab Essential Training ist speziell für Teams konzipiert, die von SVN oder anderen Systemen auf Git umsteigen. Dort vermitteln wir nicht nur Git-Befehle, sondern die Denkweise hinter Git-basierten Workflows.
