Freigeben über

Migrieren von zentralisierter Versionskontrolle zu Git

  • Artikel

Die Umstellung eines Teams von einer zentralisierten Versionskontrolle auf Git erfordert mehr als nur das Erlernen neuer Befehle. Um die verteilte Entwicklung zu unterstützen, speichert Git den Dateiverlauf und die Verzweigungsdaten anders als ein zentralisiertes Versionskontrollsystem. Die Planung und Umsetzung einer erfolgreichen Migration von einem zentralisierten Versionskontrollsystem zu Git erfordert das Verständnis dieser grundlegenden Unterschiede.

Microsoft hat viele interne Teams und Kunden bei der Umstellung von zentralisierten Versionskontrollsystemen auf Git unterstützt. Diese Erfahrung hat zu den folgenden Richtlinien geführt, die auf Praktiken basieren, die durchweg erfolgreich sind.

Schritte für eine erfolgreiche Migration

Für eine erfolgreiche Migration sollten die Teams:

  • Aktuelle Tools und Prozesse evaluieren.
  • Eine Git-Verzweigungsstrategie auswählen.
  • Entscheiden, ob und wie die Verlaufsdaten migriert werden sollen.
  • Das bisherige Versionskontrollsystem beibehalten.
  • Die binären Dateien, ausführbaren Dateien und Tools aus der Versionskontrolle entfernen.
  • Das Team in Git-Konzepten und -Praktiken schulen.
  • Die Migration zu Git testen.

Aktuelle Tools und Prozesse evaluieren

Der Wechsel von Versionskontrollsystemen unterbricht natürlich den Workflow der Entwicklung mit neuen Tools und Praktiken. Diese Unterbrechung kann eine Gelegenheit sein, andere Aspekte des DevOps-Prozesses zu verbessern.

Die Teams sollten bei der Umstellung auf das neue System die folgenden Praktiken anwenden:

  • Kontinuierliche Integration (CI), bei der jeder Check-in einen Build und Testdurchlauf auslöst. CI hilft bei der frühzeitigen Erkennung von Fehlern und bietet ein starkes Sicherheitsnetz für Projekte.

  • Erforderliche Codeüberprüfungen vor dem Überprüfen des Codes. Im Git-Verzweigungsmodell ist die Überprüfung des Codes bei Pull-Anforderungen Teil des Entwicklungsprozesses. Codeüberprüfungen ergänzen den CI Workflow.

  • Kontinuierliche Bereitstellung (CD) zur Automatisierung von Bereitstellungsprozessen. Ein Wechsel der Versionskontroll-Tools erfordert Änderungen im Bereitstellungsprozess, so dass eine Migration ein guter Zeitpunkt ist, um eine moderne Release-Pipeline einzuführen.

Eine Git-Verzweigungsstrategie auswählen.

Bevor der Code migriert wird, sollte das Team eine Verzweigungsstrategie wählen.

In Git ermöglichen kurzlebige Themenzweige den Entwicklern, in der Nähe des Hauptzweigs zu arbeiten und schnell zu integrieren, um Probleme bei der Zusammenführung zu vermeiden. Zwei gängige Strategien für Themenverzweigungen sind GitFlow und eine einfachere Variante, GitHub Flow.

Git rät von langlebigen, isolierten Feature-Zweigen ab, die dazu neigen, Zusammenführungen zu verzögern, bis die Integration schwierig wird. Durch den Einsatz moderner CD-Techniken wie Feature Flags können Teams den Code schnell in den Hauptzweig integrieren, aber dennoch die in Arbeit befindlichen Funktionen vor den Benutzern verbergen, bis sie fertig sind.

Teams, die derzeit eine Strategie für langlebige Feature-Branches verwenden, können Feature-Flags einführen, bevor sie auf Git umsteigen. Die Verwendung von Feature Flags vereinfacht die Migration, da die Anzahl der zu migrierenden Zweige minimiert wird. Unabhängig davon, ob sie Feature-Zweige oder Feature-Flags verwenden, sollten Teams die Zuordnung zwischen Legacy-Zweigen und neuen Git-Zweigen dokumentieren, damit jeder weiß, wohin er seine neue Arbeit übertragen soll.

Entscheiden Sie, ob Sie Verlaufsdaten migrieren möchten

Teams könnten versucht sein, ihre bestehenden Verlaufsdaten zu Git zu migrieren. Mehrere Tools behaupten, dass sie die kompletten Verlaufsdaten aller Zweige von einem zentralisierten Tool zu Git migrieren können. Ein Git-Commit scheint relativ gut mit dem Changeset- oder Check-in-Modell übereinzustimmen, das das vorherige Versionskontrollprogramm verwendet hat.

Diese Zuordnung hat jedoch einige schwerwiegende Einschränkungen.

  • In den meisten zentralisierten Versionskontrollsystemen existieren Zweige als Ordner im Repository. Der Hauptzweig könnte zum Beispiel ein Ordner namens /trunk sein, und andere Zweige sind Ordner wie /branch/one und /branch/two. In einem Git-Repository umfassen die Zweige das gesamte Repository, so dass eine 1:1-Übersetzung schwierig ist.

  • In einigen Versionskontrollsystemen ist ein Tag oder Label eine Sammlung, die verschiedene Dateien im Verzeichnisbaum enthalten kann, sogar Dateien mit unterschiedlichen Versionen. In Git ist ein Tag ein Schnappschuss des gesamten Repositorys zu einem bestimmten Zeitpunkt. Ein Tag kann keine Teilmenge des Repositorys repräsentieren oder Dateien mit unterschiedlichen Versionen kombinieren.

  • Die meisten Versionskontrollsysteme speichern Details über die Art und Weise, wie sich Dateien zwischen Versionen ändern, einschließlich detaillierter Änderungsarten wie Umbenennen, Rückgängigmachen und Rollback. Git speichert Versionen als Snapshots des gesamten Repositorys, und Metadaten über die Art und Weise, wie Dateien geändert wurden, sind nicht verfügbar.

Diese Unterschiede bedeuten, dass eine vollständige Migration der Verlaufsdaten bestenfalls verlustbehaftet und möglicherweise irreführend sein wird. Angesichts des Verlusts, des Aufwands und der relativen Seltenheit der Verwendung von Verlaufsdaten wird den meisten Teams empfohlen, den Import von Verlaufsdaten zu vermeiden. Stattdessen sollten Teams eine Tip-Migration durchführen, bei der nur ein Snapshot der neuesten Branch-Version in Git eingebracht wird. Für die meisten Teams ist es am besten, ihre Zeit in Bereiche der Migration zu investieren, die einen höheren Return on Investment haben, wie z. B. die Verbesserung von Prozessen.

Pflege des alten Versionskontrollsystems

Während und nach einer Migration benötigen Entwickler möglicherweise noch Zugriff auf die früheren Verlaufsdaten der Versionskontrolle. Obwohl die früheren Verlaufsdaten der Versionskontrolle im Laufe der Zeit an Bedeutung verlieren, ist es immer noch wichtig, auf sie zurückgreifen zu können. In stark regulierten Umgebungen gibt es möglicherweise spezielle rechtliche und Prüfungsanforderungen für Verlaufsdaten der Versionskontrolle.

Besonders für Teams, die nur eine Tip-Migration durchführen, ist es sehr empfehlenswert, das vorherige System auf unbestimmte Zeit beizubehalten. Setzen Sie das alte Versionskontrollsystem nach der Migration auf schreibgeschützt.

Große Entwicklungsteams und regulierte Umgebungen können in Git Hinweise platzieren, die auf das alte Versionskontrollsystem zurückverweisen. Ein einfaches Beispiel ist eine Textdatei, die als erste Übergabe im Stamm eines Git-Repositorys vor der Tip-Migration hinzugefügt wird und auf die URL des alten Versionskontrollservers verweist. Wenn viele Zweige migriert werden, sollte eine Textdatei in jedem Zweig erklären, wie die Zweige vom alten System migriert wurden. Hinweise sind außerdem hilfreich für Entwickler, die nach der Migration mit der Arbeit an einem Projekt beginnen und mit dem alten Versionskontrollsystem nicht vertraut sind.

Entfernen von Binärdateien und -tools

Das Speichermodell von Git ist für die Versionierung von Textdateien und Quellcode optimiert, die kompakt und stark komprimierbar sind. Binärdateien sind in der Regel groß, und wenn sie einmal zu einem Repository hinzugefügt wurden, bleiben sie in den Verlaufsdaten des Repositorys und in jedem zukünftigen Klon enthalten. Aufgrund der Art und Weise, wie Git Verlaufsdaten speichert, sollten Entwickler es vermeiden, Binärdateien zu Repositories hinzuzufügen, insbesondere solche, die sehr groß sind oder sich häufig ändern. Die Umstellung auf Git ist eine Gelegenheit, diese Binärdateien aus der Codebasis zu entfernen.

Es wird auch empfohlen, Bibliotheken, Tools und Build-Ausgaben von Repositories auszuschließen. Verwenden Sie stattdessen Paketverwaltungssysteme wie NuGet, um Abhängigkeiten zu verwalten.

Assets wie Symbole und Grafiken müssen möglicherweise an eine bestimmte Version des Quellcodes angepasst werden. Kleine, selten geänderte Assets wie Symbole belasten die Verlaufsdaten nicht, und Sie können sie direkt in ein Projektarchiv aufnehmen. Um große oder sich häufig ändernde Assets zu speichern, verwenden Sie die Git-Erweiterung Large File Storage (LFS). Weitere Informationen zur Verwaltung großer Dateien in GitHub, siehe Verwaltung großer Dateien. Für Azure Repos, siehe Verwalten und Speichern großer Dateien in Git.

Anbieten von Schulungen

Eine der größten Herausforderungen bei der Umstellung auf Git besteht darin, den Entwicklern zu erklären, wie Git Änderungen speichert und wie Commits die Verlaufsdaten der Entwicklung bilden. Es reicht nicht aus, einen Cheat Sheet zu erstellen, der die alten Befehle den Git-Befehlen zuordnet. Entwickler müssen aufhören, die Verlaufsdaten der Versionskontrolle als ein zentralisiertes, lineares Modell zu betrachten, und das Verlaufsmodell von Git und den Commit-Graphen verstehen.

Menschen lernen auf unterschiedliche Art und Weise, daher sollten Sie mehrere Arten von Schulungsmaterial zur Verfügung stellen. Live-Schulungen im Lab mit einem fachkundigen Schulungsleiter sind für manche Menschen gut geeignet. Das Buch Pro Git ist ein hervorragender Ausgangspunkt, der kostenlos online verfügbar ist.

Zu den verfügbaren kostenlosen praktischen Kursen gehören:

Unternehmen sollten daran arbeiten, Git-Experten in ihren Teams zu identifizieren, sie zu befähigen, anderen zu helfen, und andere Teammitglieder zu ermutigen, ihnen Fragen zu stellen.

Testen der Migration

Sobald die Teams ihre Prozesse aktualisiert, ihren Code analysiert und ihre Mitglieder geschult haben, ist es an der Zeit, den Quellcode zu migrieren. Unabhängig davon, ob Sie eine Tip-Migration oder eine Migration der Verlaufsdaten durchführen, ist es wichtig, dass Sie eine oder mehrere Testmigrationen in ein Test-Repository durchführen. Bevor Sie eine endgültige Migration durchführen, sollten Sie Folgendes überprüfen:

  • Alle Codedateien werden migriert.
  • Alle Zweige sind verfügbar.
  • Es befinden sich keine verirrten Binärdateien im Repository.
  • Die Benutzer haben die entsprechenden Berechtigungen zum Abrufen und Verschieben.
  • Die Builds sind erfolgreich und alle Tests werden bestanden.

Migration des Codes

Führen Sie die endgültige Migration in der arbeitsfreien Zeit durch, idealerweise zwischen den Etappen, wenn es eine natürliche Ausfallzeit gibt. Die Migration am Ende eines Sprints kann zu Problemen führen, während die Entwickler versuchen, ihre Arbeit zu beenden. Versuchen Sie, die Migration an einem Wochenende durchzuführen, wenn niemand die Daten überprüfen muss.

Planen Sie eine feste Umstellung vom alten Versionskontrollsystem auf Git. Der Versuch, mehrere Systeme parallel zu betreiben, bedeutet, dass Entwickler möglicherweise nicht wissen, wo oder wie sie sich überprüfen können. Setzen Sie das alte Versionskontrollsystem auf schreibgeschützt, um Verwechslungen zu vermeiden. Ohne diesen Schutz könnte eine zweite Migration mit zwischenzeitlichen Änderungen erforderlich sein.

Der eigentliche Migrationsprozess variiert je nach System, von dem Sie migrieren. Für weitere Informationen über die Migration von Team Foundation Version Control, siehe Migration von TFVC zu Git.

Migrationscheckliste

Teamworkflows:

  • Legen Sie fest, wie die Builds ablaufen sollen.
  • Entscheiden Sie, wann die Tests durchgeführt werden sollen.
  • Entwickeln Sie einen Prozess zur Versionsverwaltung.
  • Verschieben Sie Code-Reviews in Pull-Anforderungen.

Verzweigungsstrategie:

  • Wählen Sie eine Git-Verzweigungsstrategie.
  • Dokumentieren Sie die Verzweigungsstrategie, warum sie gewählt wurde und wie die alten Zweige zugeordnet werden.

History:

  • Entscheiden Sie, wie lange die Legacy-Versionskontrolle laufen soll.
  • Identifizieren Sie Zweige, die migriert werden müssen.
  • Erstellen Sie bei Bedarf Hinweise, die den Ingenieuren helfen, zum Altsystem zurück zu navigieren.

Binärdateien und Tools:

  • Bestimmen Sie, welche Binärdateien und nicht veränderbaren Dateien aus dem Repository entfernt werden sollen.
  • Entscheiden Sie sich für einen Ansatz für große Dateien, wie z. B. Git-LFS.
  • Entscheiden Sie sich für einen Ansatz zur Bereitstellung von Tools und Bibliotheken, z. B. NuGet.

Training:

  • Identifizieren Sie Schulungsmaterialien.
  • Planen Sie Schulungsveranstaltungen, schriftliche Materialien und Videos.
  • Bestimmen Sie die Mitglieder des Teams, die als lokale Git-Experten fungieren.

Code-Migration:

  • Führen Sie mehrere Testläufe durch, um sicherzustellen, dass die Migration reibungslos verläuft.
  • Legen Sie eine Cutover-Zeit fest und teilen Sie diese mit.
  • Erstellen Sie das neue Git Repo.
  • Setzen Sie das alte System auf schreibgeschützt.
  • Migrieren Sie zuerst den Hauptzweig und dann alle anderen benötigten Zweige.

Nächste Schritte