Importieren und Migrieren von Repositorys von TFVC zu Git

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Sie können Code aus einem vorhandenen TFVC-Repository zu einem neuen Git-Repository innerhalb derselben Organisation migrieren. Die Migration zu Git ist ein aufwändiger Prozess für große TFVC-Repositorys und -Teams. Zentralisierte Versionskontrollsysteme wie TFVC unterscheiden sich in wesentlichen Punkten von Git. Der Wechsel beinhaltet wesentlich mehr, als nur neue Befehle zu lernen. Es handelt sich um eine disruptive Änderung, die eine sorgfältige Planung erfordert. Sie müssen Folgendes berücksichtigen:

• Überarbeiten von Tools und Prozessen
• Entfernen von Binärdateien und ausführbaren Dateien
• Trainieren Ihres Teams

Sie sollten unbedingt die zentrale Versionskontrolle für Git und den folgenden Abschnitt Migrieren von TFVC zu Git lesen, bevor Sie mit der Migration beginnen.

Die Importumgebung eignet sich hervorragend für kleine einfache TFVC-Repositorys. Sie eignet sich außerdem für Repositorys, die bereits „bereinigt“ wurden, wie in der zentralen Versionssteuerung für Git und im folgendem Abschnitt Migration von TFVC zu Git beschrieben. In diesen Abschnitten werden auch andere Tools für erweiterte TFVC-Repository-Konfigurationen empfohlen.

Wichtig

Aufgrund der Unterschiede in der Art und Weise, wie TFVC und Git den Verlauf der Versionskontrolle speichern, empfehlen wir, dass Sie Ihren Verlauf nicht migrieren. Dies ist auch der Ansatz, den Microsoft verfolgt hat, als Windows und andere Produkte von der zentralen Versionskontrolle zu Git migriert wurden.

Importieren des Repositorys

1. Wählen Sie Repositorys, Dateien aus.

   

2. Wählen Sie in der Dropdownliste der Repositorys Repository importieren aus.

   

3. Wählen Sie TFVC in der Dropdownliste Quelltyp aus.

4. Geben Sie den Pfad zu dem Repository/Branch/Ordner ein, das/den Sie in das Git-Repository importieren möchten. Beispiel: $/Fabrikam/FabrikamWebsite

5. Wenn Sie den Verlauf aus dem TFVC-Repository migrieren möchten, klicken Sie auf Verlauf migrieren, und wählen Sie dann die Anzahl der Tage aus. Sie können einen Verlauf von bis zu 180 Tagen migrieren, beginnend mit dem neuesten Changeset. Ein Link zum TFVC-Repository wird in der Commitnachricht des ersten Changesets hinzugefügt, das zu Git migriert wird. So können Sie bei Bedarf leicht ältere Verläufe finden.

6. Geben Sie dem neuen Git-Repository einen Namen, und klicken Sie auf Importieren. Je nach Umfang des Imports wäre Ihr Git-Repository in wenigen Minuten fertig.

   

Problembehandlung

Diese Umgebung ist für kleine, einfache TFVC-Repositorys oder Repositorys, die für eine Migration vorbereitet wurden, optimiert. Das bedeutet, dass es ein paar Einschränkungen gibt.

1. Es wird nur der Inhalt des Stammverzeichnisses oder eines Branchs migriert. Wenn Sie z. B. über ein TFVC-Projekt bei $/Fabrikam verfügen, das einen untergeordneten Branch und einen untergeordneten Ordner umfasst, würde ein Pfad zum Importieren von $/Fabrikam den Ordner importieren, während $/Fabrikam/<branch> nur den Branch importieren würde.
2. Das importierte Repository und der zugeordnete Verlauf (falls importiert) dürfen eine Größe von 1 GB nicht überschreiten.
3. Sie können den Verlauf von bis zu 180 Tagen importieren.

Wenn eine der oben genannten Begrenzungen Ihren Import beeinträchtigt, empfehlen wir Ihnen, externe Tools wie Git-TFS zum Importieren und Lesen unserer Whitepaper auszuprobieren: Zentrale Versionskontrolle für Git und der folgende Abschnitt Migrieren von TFVC zu Git.

Wichtig

Die Verwendung externer Tools wie Git-TFS mit Microsoft-Produkten, -Diensten oder -Plattformen liegt in der Verantwortung des Benutzers. Microsoft unterstützt oder garantiert nicht die Funktionalität, Zuverlässigkeit oder Sicherheit solcher Drittanbietererweiterungen nicht.

Migrieren von der TFVC nach Git

Bevor Sie Quellcode von einem zentralisierten Versionskontrollsystem zu Git migrieren, sollten Sie sich mit den Unterschieden zwischen den beiden Systemen vertraut machen und die Migration vorbereiten.

• Anforderungen
• Migrationsschritte
  • Probieren Sie die neueste Version aus
  • Binärdateien und Build-Tools entfernen
  • Konvertierung der versionskontrollspezifischen Konfiguration
  • Änderungen einchecken und die Migration durchführen
  • Erweiterte Migrationen
• Aktualisieren Sie den Arbeitsablauf

Anforderungen

Um Migrationen zu erleichtern, sind im vorherigen Abschnitt dieses Artikels einige Anforderungen aufgeführt, die erfüllt werden müssen, bevor Sie mit dem Prozess des Importierens des Repositorys fortfahren.

• Migrieren Sie nur einen einzigen Zweig. Wenn die Migration plant, wählen Sie eine neue Verzweigungsstrategie für Git. Die Migration nur des Hauptzweigs unterstützt einen Topic-Branch-basierten Workflow wie GitFlow oder GitHub Flow.
• Führen Sie eine Tipp-Migration durch, d. h. importieren Sie nur die neueste Version des Quellcodes. Wenn die TFVC-Historie einfach ist, gibt es die Möglichkeit, einen Teil der Historie zu migrieren, bis zu 180 Tage, so dass das Team nur aus Git heraus arbeiten kann. Weitere Informationen finden Sie unter Planen Sie Ihre Migration zu Git.
• Schließen Sie binäre Assets wie Bilder, wissenschaftliche Datensätze oder Spielmodelle aus dem Repository aus. Diese Assets müssen die Git LFS-Erweiterung (Large File Storage) verwenden, die das Importwerkzeug nicht konfiguriert.
• Halten Sie die Größe des importierten Repositorys unter 1 GB.

Wenn das Repository diese Anforderungen nicht erfüllt, verwenden Sie stattdessen das Git-TFS-Tool, um Ihre Migration durchzuführen.

Wichtig

Die Verwendung externer Tools wie Git-TFS mit Microsoft-Produkten, -Diensten oder -Plattformen liegt in der Verantwortung des Benutzers. Microsoft unterstützt oder garantiert nicht die Funktionalität, Zuverlässigkeit oder Sicherheit solcher Drittanbietererweiterungen nicht.

Migrationsschritte

Die Migration von TFVC ist in der Regel einfach zu bewerkstelligen:

1. Informieren Sie sich über die neue Version des Zweigs von TFVC auf Ihrer lokalen Festplatte.
2. Entfernen Sie die Binärdateien und Build-Tools aus dem Repository und richten Sie ein Paketverwaltungssystem wie NuGet ein.
3. Konvertieren Sie die systemeigenen Direktiven der Versionskontrolle. Konvertieren Sie zum Beispiel .tfignore in .gitignoreund .tpattributes in .gitattributes.
4. Checken Sie Änderungen ein und führen Sie die Migration zu Git durch.

Die Schritte 1-3 sind optional. Wenn im Repository keine Binärdateien vorhanden sind und es nicht erforderlich ist, eine oder eine .gitignore oder eine .gitattributeseinzurichten, können Sie direkt mit dem Einchecken von Änderungen fortfahren und den Migrationsschritt ausführen.

Probieren Sie die neueste Version aus

Erstellen Sie einen neuen TFS-Arbeitsbereich und ordnen Sie einen Arbeitsordner für das Serververzeichnis zu, das zu Git migriert wird. Dies erfordert keine vollständige Zuordnung der Arbeitsordner. Ordnen Sie nur Ordner zu, die Binärdateien enthalten, die aus dem Repository entfernt werden sollen, und Ordner, die versionskontrollsystemspezifische Konfigurationsdateien wie .tfignoreenthalten.

Sobald die Zuordnungen eingerichtet sind, rufen Sie den Ordner lokal ab:

tf get /version:T /recursive

Binärdateien und Build-Tools entfernen

Aufgrund der Art und Weise, wie Git die Historie geänderter Dateien speichert, indem es jedem Entwickler eine Kopie jeder Datei in der Historie zur Verfügung stellt, führt das Einchecken von Binärdateien direkt in das Repository dazu, dass das Repository schnell wächst und Leistungsprobleme verursacht.

Für Build-Tools und Abhängigkeiten wie Bibliotheken müssen Sie eine Paketierungslösung mit Versionierungsunterstützung wie NuGet verwenden. Viele Open-Source-Tools und -Bibliotheken sind bereits in der NuGet Galleryverfügbar. Für proprietäre Abhängigkeiten müssen Sie jedoch neue NuGet-Pakete erstellen.

Sobald die Abhängigkeiten in NuGet verschoben wurden, stellen Sie sicher, dass sie nicht in das Git-Repository aufgenommen werden, indem Sie sie zu .gitignorehinzufügen.

Konvertierung der versionskontrollspezifischen Konfiguration

Team Foundation Version Control stellt eine .tfignore Datei zur Verfügung, die sicherstellt, dass bestimmte Dateien nicht zum TFVC Repository hinzugefügt werden. Sie können die Datei .tfignore für automatisch generierte Dateien wie die Build-Ausgabe verwenden, damit diese nicht versehentlich eingecheckt werden.

Wenn das Projekt auf dieses Verhalten angewiesen ist, konvertieren Sie die Datei .tfignore in eine Datei .gitignore.

Plattformübergreifende TFVC-Clients bieten auch Unterstützung für eine .tpattributes -Datei, die steuert, wie Dateien auf der lokalen Festplatte abgelegt oder in das Repository eingecheckt werden. Wenn eine Datei .tpattributes verwendet wird, konvertieren Sie sie in eine Datei .gitattributes.

Änderungen einchecken und die Migration durchführen

Checken Sie alle Änderungen ein, die Binärdateien entfernen, zur Paketverwaltung migrieren oder die versionskontrollspezifische Konfiguration konvertieren. Sobald Sie diese letzte Änderung in TFVC vorgenommen haben, können Sie den Import durchführen.

Folgen Sie dem Verfahren zum Importieren des Repositorys, um den Import durchzuführen.

Erweiterte Migrationen

Das Git-TFS-Tool ist eine bidirektionale Brücke zwischen Team Foundation Version Control und Git, mit der Sie eine Migration durchführen können. Git-TFS eignet sich für eine Migration mit vollständiger Historie, d. h. mehr als die 180 Tage, die das Import-Tool unterstützt. Oder Sie können Git-TFS verwenden, um eine Migration zu versuchen, die mehrere Zweige und Zusammenführungsbeziehungen umfasst.

Bevor Sie eine Migration mit Git-TFS versuchen, müssen Sie beachten, dass es grundlegende Unterschiede zwischen der Art und Weise gibt, wie TFVC und Git den Verlauf speichern:

• Git speichert die Historie als einen Schnappschuss des Repositorys in der Zeit, während TFVC die einzelnen Operationen aufzeichnet, die an einer Datei durchgeführt wurden. Änderungsarten in TFVC wie Umbenennen, Rückgängigmachen und Rollback können in Git nicht ausgedrückt werden. Anstatt zu sehen, dass die Datei A in die Datei Bumbenannt wurde, wird nur verfolgt, dass die Datei A gelöscht und die Datei B in der gleichen Übertragung hinzugefügt wurde.
• Für Git gibt es keine direkte analoge Entsprechung zu einem TFVC-Label. Labels können eine beliebige Anzahl von Dateien in einer bestimmten Version enthalten und können Dateien in verschiedenen Versionen widerspiegeln. Obwohl konzeptionell ähnlich, verweisen die Git-Tags auf eine Momentaufnahme des gesamten Repositorys zu einem bestimmten Zeitpunkt. Wenn das Projekt auf TFVC-Labels angewiesen ist, um zu wissen, was geliefert wurde, liefern die Git-Tags diese Informationen möglicherweise nicht.
• Zusammenführungen in TFVC finden auf Dateiebene statt, nicht im gesamten Repository. Nur eine Teilmenge der geänderten Dateien kann von einem Zweig zum anderen zusammengeführt werden. Verbleibende geänderte Dateien können dann in einem nachfolgenden Änderungssatz zusammengeführt werden. In Git wirkt sich eine Zusammenführung auf das gesamte Repository aus, und beide Gruppen von Einzeländerungen können nicht als Zusammenführung betrachtet werden.

Aufgrund dieser Unterschiede wird empfohlen, dass Sie eine Tipp-Migration durchführen und Ihr TFVC-Repository online, aber schreibgeschützt lassen, um den Verlauf zu sehen.

Um eine erweiterte Migration mit Git-TFS zu versuchen, siehe clone a single branch with history oder clone all branches with merge history.

Wichtig

Die Verwendung externer Tools wie Git-TFS mit Microsoft-Produkten, -Diensten oder -Plattformen liegt in der Verantwortung des Benutzers. Microsoft unterstützt oder garantiert nicht die Funktionalität, Zuverlässigkeit oder Sicherheit solcher Drittanbietererweiterungen nicht.

Aktualisieren Sie den Arbeitsablauf

Der Wechsel von einer zentralisierten Versionskontrolle zu Git umfasst mehr als nur die Migration von Code. Das Team muss geschult werden, um zu verstehen, wie sich Git von dem bestehenden Versionskontrollsystem unterscheidet und wie sich diese Unterschiede auf die tägliche Arbeit auswirken.

Erfahren Sie mehr darüber, wie Sie von einer zentralen Versionskontrolle zu Gitmigrieren.