Informationen zu Migrationen von Azure DevOps zu GitHub Enterprise Cloud

Erfahren Sie, welche Daten GitHub Enterprise Importer migrieren kann.

In diesem Artikel

Informationen zum Migrieren von Azure DevOps

Mit GitHub Enterprise Importer können Sie Repositorys von Azure DevOps zu GitHub Enterprise Cloud migrieren.

Du kannst GitHub Enterprise Importer nur verwenden, um von Azure DevOps Cloud zu migrieren, nicht von Azure DevOps Server. Wenn du derzeit Azure DevOps Server verwendest und zu GitHub migrieren möchtest, kannst du zuvor zu Azure DevOps Cloud migrieren. Weitere Informationen findest du auf der Azure-Website unter Migrieren zu Azure DevOps.

Migrierte Daten

Derzeit wird nur die Migration der folgenden Repositorydaten von Azure DevOps zu GitHub Enterprise Cloud unterstützt.

  • Git-Quelle (einschließlich Commitverlauf)
  • Pull Requests
  • Benutzerverlauf für Pull Requests
  • Arbeitselementlinks in Pull Requests
  • Anlagen von Pull Requests
  • Branch-Richtlinien für das Repository (benutzerspezifische Branch-Richtlinien und Repo-übergreifende Branch-Richtlinien für Repositorys sind nicht enthalten)

Wenn du von Azure Pipelines zu GitHub Actions migrieren möchtest, wende dich an deinen GitHub-Kontomanagerin.

Einschränkungen bei migrierten Daten

Es gelten Einschränkungen dafür, was GitHub Enterprise Importer migrieren kann. Einige sind auf Einschränkungen von GitHub.com zurückzuführen, während andere Einschränkungen durch GitHub Enterprise Importer selbst verursacht werden.

Einschränkungen von GitHub.com

  • Größenbeschränkung von 2 GB für einen einzelnen Git-Commit: Kein einzelner Commit in deinem Git-Repository darf größer als 2 GB sein. Wenn einer deiner Commits größer als 2 GB ist, musst du den Commit in kleinere Commits aufteilen, die jeweils 2 GB oder kleiner sind.
  • Grenzwert von 255 Byte für Git-Verweise: Kein einzelner Git-Verweis (allgemein als „Ref“ bezeichnet) darf einen Namen haben, der größer als 255 Byte ist. In der Regel bedeutet dies, dass deine Verweise nicht mehr als 255 Zeichen lang sein dürfen, aber Nicht-ASCII-Zeichen wie z. B. Emojis können mehr als ein Byte groß sein. Wenn einer deiner Git-Verweise zu groß ist, wird eine eindeutige Fehlermeldung zurückgegeben.
  • Dateigrößenbeschränkung von 100 MB: Keine einzelne Datei in deinem Git-Repository darf größer als 100 MB sein. Erwäge die Verwendung von Git LFS zum Speichern großer Dateien. Weitere Informationen findest du unter Große Dateien verwalten.

Einschränkungen von GitHub Enterprise Importer

  • Größenbeschränkung von 10 GB für ein Git-Repository: Dieser Grenzwert gilt nur für den Quellcode. Um zu überprüfen, ob das Repositoryarchiv den Grenzwert überschreitet, verwenden Sie das Git-Sizer-Tool, und überprüfen Sie die Gesamt-BLOB-Größe in der Ausgabe. Das Git-Sizer-Tool hilft auch, potenzielle Probleme im Zusammenhang mit großen Dateien, BLOB-Größe, Commit-Größe und Strukturanzahl zu identifizieren, die sich auf Migrationen auswirken könnten.
  • Grenzwert von 10 GB für Metadaten: Importer kann keine Repositorys mit mehr als 10 GB Metadaten migrieren. Zu den Metadaten gehören Issues, Pull Requests, Releases und Anlagen. In den meisten Fällen werden große Metadaten durch binäre Ressourcen verursacht, die an Releases angefügt sind. Du kannst Releases mit dem Flag --skip-releases des Befehls migrate-repo von der Migration ausschließen und deine Releases dann nach der Migration manuell verschieben.
  • Git LFS-Objekte werden nicht migriert: Importer kann Repositorys migrieren, die Git LFS verwenden, aber die LFS-Objekte selbst werden nicht migriert. Sie können nach Abschluss der Migration als Nachverfolgungsaufgabe in dein Migrationsziel gepusht werden. Weitere Informationen findest du unter Ein Repository duplizieren.
  • Erforderliche Folgeaufgaben: Bei der Migration zwischen GitHub-Produkten werden bestimmte Einstellungen nicht migriert und müssen im neuen Repository neu konfiguriert werden. Eine Liste der Folgeaufgaben, die du nach jeder Migration ausführen musst, findest du unter Übersicht über die Migration zwischen GitHub-Produkten.
  • Verzögerte Funktionalität der Codesuche: Die erneute Indizierung des Suchindex kann einige Stunden dauern, nachdem ein Repository migriert wurde, und die Codesuche kann unerwartete Ergebnisse zurückgeben, bis die erneute Indizierung abgeschlossen ist.
  • Für deine Organisation konfigurierte Regelsätze können zu Migrationsfehlern führen: Wenn du beispielsweise eine Regel konfiguriert hast, die voraussetzt, dass E-Mail-Adressen von Commitautor*innen mit @monalisa.cat enden, und das zu migrierende Repository Commits enthält, die dieser Regel nicht entsprechen, schlägt die Migration fehl. Weitere Informationen zu Regelsätzen findest du unter Informationen zu Regelsätzen.
  • Mannequin-Inhalte sind möglicherweise nicht durchsuchbar: Mannequins sind Platzhalterbenutzer, denen importierte Inhalte (z. B. Probleme, Pull Requests, Kommentare usw.) zugeordnet sind. Wenn du nach Inhalten suchst, die einem Mannequin zugeordnet sind, z. B. zugewiesene Issues, werden die Issues möglicherweise nicht gefunden. Sobald ein Mannequin zurückgenommen wird, sollte der Inhalt über den neuen Besitzer gefunden werden. Weitere Informationen findest du unter Freigeben von Mannequins für GitHub Enterprise Importer.

Erste Schritte

Bevor Sie von Azure DevOps migrieren, sollten Sie die Art der Ausführung der Migration planen. Bevor Sie Daten migrieren, müssen Sie eine Person auswählen, die die Migration ausführen soll. Sie müssen dieser Person den erforderlichen Zugriff sowohl auf die Quelle als auch auf das Ziel der Migration gewähren. Außerdem empfehlen wir, zuerst eine Testmigration vorzunehmen.

Eine Übersicht über den Migrationsprozess von Anfang bis Ende finden Sie unter „Übersicht über die Migration von Azure DevOps zu GitHub Enterprise Cloud“.