Software-Versionskontrolle: Beratung zum Umstieg nach Git

Konzepte der Software-Versionskontrolle

• Wozu Versionskontrolle dient: Nachvollziehbarkeit, Wiederherstellung, parallele Arbeit
• Zentrale und verteilte Systeme: Server als einzige Quelle oder vollständige Kopie bei jedem Clone
• Was ein Repository enthält: Revisionen, Changesets bzw. Commits und ihre Kennungen je System
• Wie ein Repository arbeitet: Arbeitskopie, Checkout, Commit, Update bzw. Pull
• Dateien hinzufügen, entfernen und ignorieren: svn:ignore, .tfignore, .p4ignore, .hgignore
• Verzweigen und Zusammenführen: Verzeichniskopie, Stream, benannter Branch oder leichter Zeiger
• Sperren statt Mergen: exklusives Auschecken für Dateien, die sich nicht zusammenführen lassen
• Fehler korrigieren: Rücknahme als neue Revision statt Löschen aus der Historie
• Konflikte erkennen und lösen: was die Systeme unterschiedlich gut automatisch zusammenführen

Git – das Zielsystem im Überblick

• Wie Git sich von den anderen Systemen unterscheidet: komplette Historie lokal, Commit-Hash statt Revisionsnummer
• Repositories anlegen oder klonen; ein Bare-Repository als zentrales Ziel der Migration
• Befehle für Umsteiger: Subversion- und Git-Befehle in einer Tabelle gegenübergestellt
• Zu früheren Versionen zurück: git revert für geteilte Historie, git restore für einzelne Dateien
• Verzweigen in Git: warum Teams nach dem Umstieg häufiger und kurzlebiger verzweigen
• Grafische Clients und IDE-Integration: VS Code, Visual Studio, JetBrains-IDEs, TortoiseGit für Tortoise-Umsteiger
• GitHub, GitLab, Bitbucket und Azure Repos als Ziel für migrierte Repositories

Azure Repos: Git, TFVC und der Weg nach Git

• Wie Azure Repos funktionieren: Git-Repositories und TFVC im selben Azure-DevOps-Projekt
• Das TFVC-Modell: Workspaces, ausstehende Änderungen, Changesets und Shelvesets
• Repositories in Azure DevOps anlegen: Git als Vorgabe, TFVC nur noch für Bestände
• Dateien hinzufügen und entfernen in TFVC und Git im Vergleich, .tfignore gegenüber .gitignore
• Branch-Richtlinien in Azure Repos: Pull Requests, Build-Validierung und Mindestzahl an Reviewer:innen
• Import-Funktion von Azure Repos: TFVC nach Git mit begrenzter Historie
• Vollständige Historie mit git-tfs übernehmen, wenn sie gebraucht wird – das Werkzeug wird nicht mehr aktiv gepflegt
• TFVC-Ordnerbranches auf Git-Branches abbilden – und welche besser im Archiv bleiben
• Builds und Pipelines von TFVC-Pfadfiltern auf Git-Trigger umstellen

Subversion und der Umstieg nach Git

• Wie Subversion funktioniert: zentraler Server, fortlaufende Revisionsnummern, Arbeitskopie
• Repositories mit svnadmin create anlegen, Konvention trunk, branches, tags
• Dateien mit svn add und svn delete verwalten, Eigenschaften wie svn:ignore setzen
• Zu früheren Versionen: svn revert lokal, svn merge -c -<rev> für bereits committete Änderungen
• Verzweigen mit svn copy, Zusammenführen mit Merge-Tracking über svn:mergeinfo
• Teil-Checkouts einzelner Verzeichnisse und svn:externals: was Git anders löst
• Autorendatei: Subversion-Benutzernamen auf Namen und E-Mail-Adressen abbilden
• Migration mit git svn clone --stdlayout für kleine und mittlere Repositories
• Große oder unregelmäßig aufgebaute Repositories mit Regeldateien in svn-all-fast-export konvertieren
• SVN-Tags als echte Git-Tags anlegen, svn:ignore in .gitignore und svn:externals in Submodule übersetzen
• Übergang planen: Altsystem einfrieren und nur noch lesend anbieten statt Parallelbetrieb

Perforce P4 (früher Helix Core) und der Weg nach Git

• Wie P4 funktioniert: Server mit Depots, Workspaces als Client-Spezifikation, Changelists
• Repositories in P4 anlegen: Depots und Streams für Mainline, Entwicklung und Release
• Grundlegende Befehle: p4 sync, p4 edit, p4 add, p4 submit und der grafische Client P4V
• Zu früheren Versionen: Changelists mit p4 undo zurücknehmen, Dateien mit p4 revert verwerfen
• Verzweigen und Zusammenführen zwischen Streams mit p4 merge, p4 copy und p4 integrate
• Exklusive Sperren für Binärdateien und warum Spieleentwicklung oft bei Perforce bleibt
• git p4 clone für einzelne Depot-Pfade, Historie ab einer gewählten Changelist
• Wann ein Schnitt ohne Historie besser ist: letzter Stand nach Git, Depot lesend archivieren
• Große Assets in Git LFS auslagern oder bewusst hybrid bei Perforce lassen
• Sperren nachbilden mit dem Attribut lockable und git lfs lock

Mercurial und die Konvertierung nach Git

• Wie Mercurial funktioniert: verteilt wie Git, Changesets mit lokaler Nummer und globalem Hash
• Mercurial-Repositories mit hg init und hg clone erstellen
• Grundlegende Befehle: hg add, hg commit, hg pull, hg update und hg push
• GUI-Clients und IDE-Anbindung: TortoiseHg und Erweiterungen für Editoren
• Zu früheren Versionen: hg revert, hg backout und Phasen gegen das Umschreiben veröffentlichter Changesets
• Verzweigen mit benannten Branches, Bookmarks und anonymen Köpfen, Zusammenführen mit hg merge
• Konvertierung mit hg-fast-export, Autorenzuordnung und Bereinigung von Branch-Namen
• Benannte Branches und Bookmarks auf Git-Branches abbilden, geschlossene Branches als Tags archivieren
• Hosting-Wechsel: wenn der bisherige Anbieter keine Mercurial-Repositories mehr unterstützt
• .hgignore, Hooks und Unter-Repositories aus .hgsub in Git-Entsprechungen übersetzen

Große Binärdateien mit Git LFS

• Wann Git LFS nötig ist: Grafiken, Audio, CAD-Modelle, eingecheckte Werkzeuge
• Dateitypen mit git lfs track erfassen und die Regeln in .gitattributes versionieren
• Bestehende Historie messen mit git lfs migrate info und umschreiben mit git lfs migrate import
• Speicherkontingente und LFS-Unterstützung von GitHub, GitLab und Azure Repos vorab klären

Monorepo oder viele Repositories

• Ein großes Repository oder viele: Kriterien aus Build, Zugriffsrechten und Release-Zyklen
• Große Repositories schnell halten: partielles Klonen mit --filter=blob:none und sparse-checkout
• scalar und git maintenance für Hintergrundpflege sehr großer Repositories
• Repositories nach der Migration aufteilen oder zusammenführen mit git filter-repo
• Pfadbezogene Rechte aus Perforce und Subversion: in Git über getrennte Repositories und Code-Owner-Regeln

Migration planen und abnehmen

• Bestandsaufnahme: Größe, Branches, Binäranteil, Hooks und angebundene Werkzeuge
• Probelauf, Abnahme durch Vergleich der Dateibäume je Tag, Stichtag und Einweisung des Teams
• Verweise auf alte Revisionsnummern in Tickets und Dokumentation über eine Zuordnungstabelle auflösen

Versionskontrolle mit Coding-Agenten migrieren

• Agent erzeugt die Autorendatei aus svn log oder p4 users; unklare Zuordnungen klärt das Team
• Konvertierung der Versionskontrolle als wiederholbares Skript: jeder Probelauf des Agenten schreibt in ein frisches Ziel-Repository
• Abnahmeskript vom Agenten: Dateibäume je Tag in Alt- und Zielsystem vergleichen, Abweichungen auflisten
• Build-Skripte mit SVN-Revisionsnummern oder $Id$-Schlüsselwörtern auf git describe umstellen lassen
• Nur Lesezugriff auf das Altsystem; Push ins Ziel und Abschalten des alten Servers bleiben beim Team

Praxisprojekt: Subversion-Repository mit Grafikbestand nach Git umziehen

• Ein bereitgestelltes SVN-Repository mit abweichendem Layout analysieren und die Autorendatei anlegen
• Konvertieren, Branches und Tags prüfen, große Grafikdateien mit git lfs migrate auslagern
• Ergebnis nach GitLab oder Azure Repos pushen und die Abnahme gegen das Original durchführen

Lernziele

• Sie erklären die Unterschiede zwischen zentraler und verteilter Versionskontrolle und ordnen Git, TFVC, Subversion, Perforce und Mercurial ein
• Sie führen Grundoperationen, Rücknahmen sowie Verzweigen und Zusammenführen in jedem der fünf Systeme aus
• Sie wählen für ein Bestandssystem den passenden Migrationsweg nach Git und übernehmen die Historie mit Autorenzuordnung
• Sie lagern große Binärdateien mit Git LFS aus und schreiben bestehende Historie dafür um
• Sie entscheiden begründet zwischen Monorepo und mehreren Repositories und erstellen einen Migrationsplan mit Abnahmekriterien

Zielgruppe

• Teams und IT-Leitungen mit Subversion-, TFVC-, Perforce- oder Mercurial-Beständen
• Projektleitungen und Architekt:innen vor der Wahl eines Versionskontrollsystems
• Build- und Release-Verantwortliche, die eine Migration technisch umsetzen