Skip to main content

Grundlegendes zu Migrationen von GitLab zu GitHub

GitHub Enterprise Importer automatisiert Migrationen von GitLab.

Informationen zu Migrationen von GitLab

Sie können Repositorys von GitLab zu GitHub Enterprise Importer (GitHub Enterprise Cloud oder GitHub.com) migrierenGHE.com.

Migrationen werden mit dem GL2GH extension of the GitHub CLIplattformübergreifenden Befehlszeilenwrapper um die GitHub Migrations-APIs durchgeführt. Für jedes Repository:GL2GH extension

  1. Exportiert das GitLab-Projekt in ein .tar.gz Archiv, das das Git-Repository sowie Projektmetadaten enthält (z. B. Probleme, Zusammenführungsanforderungen, Bezeichnungen, Meilensteine und Versionen).
  2. Stellt das Archiv lokal auf dem Computer bereit, auf dem Sie den Befehl ausführen.
  3. Lädt das Archiv in BLOB-Speicher hoch, aus dem Sie lesen können (entweder GitHub oder ein Speicherkonto, GitHub-owned blob storage das Sie in AWS S3 oder Azure Blob Storage besitzen).
  4. Importiert das Archiv in die Zielorganisation, wobei GitLab-Entitäten in ihre GitHub Entsprechungen umgewandelt werden.

Bevor Sie Ihr Unternehmenskonto auf GitHub erstellen, entscheiden Sie, ob Ihr Unternehmen Enterprise Managed Users verwenden wird. Dies wirkt sich darauf aus, wie Sich Ihre Mitglieder authentifizieren und wie Sie Identitäten und Zugriff verwalten. Siehe Auswählen eines Unternehmenstyps für GitHub Enterprise Cloud.

Unterstützte GitLab-Versionen

Sie können von GitLab.com- und selbstverwalteten GitLab-Instanzen migrieren.

GitHub Enterprise Importer unterstützt derzeit verwaltete (nicht ende-of-life)-Versionen von GitLab. Eine Liste der verwalteten Versionen finden Sie in der GitLab-Dokumentation zur Unterstützungserklärung . Ältere Versionen wurden nicht getestet oder ausgewertet.

Migrierte Daten

Wenn die Daten im GitLab-Exportarchiv vorhanden sind, GitHub Enterprise Importer migriert sie die folgenden Daten von GitLab zu GitHub Enterprise Cloud.

  • Git-Quelle (einschließlich Commitverlauf) und repositorywiki
  • Commit-Kommentare
  • Project Konfiguration, die sauber zugeordnet wird, z. B. der Standardverzweigung
  • Probleme und Problemkommentare, einschließlich Problemstatus- und Meilensteinereignissen
    • Threaddiskussionen werden als flache Kommentare mit Kontext des ursprünglichen Threads migriert.
  • Zusammenführen von Anforderungen, die in Pullanforderungen konvertiert werden, einschließlich:
    • Kommentare (migriert als Rezensionskommentare nur, wenn Diff-Daten vorhanden sind, andernfalls als flache Problemkommentare; nur der neueste Diff ist im Export vorhanden)
    • Prüfer und Genehmigende
    • Zusammenführen von Anforderungsstatusereignissen
  • Meilensteine
  • Zeitachsenereignisse
  • Emoji-Reaktionen
  • Uploads (Anlagen)
  • Versionen und Freigeben von Ressourcen
  • Project Mitglieder (migriert als Mannequins)

Nicht migrierte Daten

Die folgenden Daten werden nicht migriert.

  • Git LFS objects: Zeigerdateien werden mit dem Git-Verlauf übertragen, aber die binären Objekte müssen separat als Nachverfolgungsaufgabe an Ihr Migrationsziel übertragen werden. Weitere Informationen findest du unter Ein Repository duplizieren.
  • Repositoryrichtlinien, einschließlich Zusammenführen von Zügen, Pipelinetoren, erforderlichen Genehmigungen, Themen, Avataren und Spiegelung
  • Gruppeneinstellungen und Gruppenmitgliedschaft
  • Codeausschnitte, Problemtafeln, Zeitverfolgungsdaten und Entwurfsverwaltungsdaten
  • CI/CD-Pipelines und Pipelinezeitpläne (.gitlab-ci.yml hat keine automatische GitHub Actions Entsprechung)
  • Sicherheitsrisikoberichte
  • Daten, die GitLab überhaupt nicht in den Export einschließt, z. B. Webhooks, CI/CD-Variablen, Auftragsablaufverfolgungen und Artefakte, Untergeordneter Pipelineverlauf und Pipelinetrigger

Einschränkungen bei migrierten Daten

Es gibt Beschränkungen dafür, was GitHub Enterprise Importer migrieren kann. Einige sind auf Einschränkungen GitHubzurückzuführen, während andere Einschränkungen von GitHub Enterprise Importer sich selbst sind.

Einschränkungen von GitHub

  • 2 GiB-Größenbeschränkung für einen einzelnen Git-Commit: Kein einzelner Commit in Ihrem Git-Repository kann größer als 2 GiB sein. Wenn eines Ihrer Commits größer als 2 GiB ist, müssen Sie den Commit in kleinere Commits aufteilen, die jeweils 2 GiB oder kleiner sind.
  • 2 GiB-Größenbeschränkung für einen einzelnen Push: Kein einzelner Push kann größer als 2 GiB sein. Größere Pushs schlagen mit einem pack exceeds maximum allowed size Fehler fehl.
  • Grenzwert von 255 Byte für Git-Verweise: Kein einzelner Git-Verweis, der allgemein als "Ref" bezeichnet wird, kann einen Namen haben, der größer als 255 Byte ist. In der Regel bedeutet dies, dass Ihre Verweise nicht mehr als 255 Zeichen lang sind, aber alle Nicht-ASCII-Zeichen, z. B. Emojis, können mehr als ein Byte verbrauchen. Wenn einer deiner Git-Verweise zu groß ist, wird eine eindeutige Fehlermeldung zurückgegeben.
  • Dateigrößenbeschränkung von 100 MiB: Nach Abschluss der Migration kann keine einzelne Datei in Ihrem Git-Repository größer als 100 MiB sein. Während der Repositorymigration wird dieser Grenzwert auf 400 MiB erhöht. Erwägen Sie die Verwendung Git LFS , um große Dateien zu speichern.

Einschränkungen von GitHub Enterprise Importer

  • Grenzwert für die Größe von 40 GB für ein Git-Repository (Öffentliche Vorschau): 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.
  • Dateigrößenbeschränkung von 400 MiB: Beim Migrieren eines Repositorys mit GitHub Enterprise Importer, kann keine einzelne Datei in Ihrem Git-Repository größer als 400 MiB sein. Erwägen Sie die Verwendung Git LFS zum Speichern großer Dateien.
  • Git LFS Nicht migrierte Objekte: Die Importer können Repositorys, die Git LFS verwenden, migrieren, aber die LFS-Objekte selbst werden nicht migriert. Sie können nach Abschluss der Migration als Folgeaufgabe an dein Migrationsziel verschoben werden.
  • 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.
  • Mannequin-Inhalte sind möglicherweise nicht durchsuchbar: Mannequins sind Platzhalterbenutzer, denen importierte Inhalte (z. B. Probleme, Pull Requests, Kommentare usw.) zugeordnet sind. Wenn Sie nach Inhalten suchen, die einem Modell zugeordnet sind, z.B. zugewiesene Probleme, können diese möglicherweise nicht gefunden werden. Sobald ein Mannequin zurückgenommen wird, sollte der Inhalt über den neuen Besitzer gefunden werden.

Einschränkungen von GitLab

  • Grenzwert von 40 GB für das GitLab-Exportarchiv: Die Projektexport-API von GitLab erzeugt kein Archiv von mehr als 40 GB auf GitLab.com. Im Gegensatz zum Grenzwert für die GitHub Quellgröße gilt dies für das gesamte Exportarchiv, einschließlich Projektmetadaten sowie der Git-Quelle. Dieser Grenzwert wird von GitLab festgelegt und kann sich bei selbstverwalteten Instanzen unterscheiden.