Informationen zu Migrationen zwischen GitHub-Produkten

Erfahren Sie, welche Daten GitHub Enterprise Importer zwischen den Produkten übertragen GitHub werden.

In diesem Artikel

Informationen zu Migrationen zwischen GitHub-Produkten

Mit GitHub Enterprise Importer kannst du Daten von GitHub Enterprise Server auf GitHub Enterprise Cloud migrieren oder Daten von GitHub.com auf ein anderes Konto auf GitHub Enterprise Cloud migrieren.

Zum Beispiel kann GitHub Enterprise Importer deinem Unternehmen dabei helfen:

  • Adaption von GitHub Enterprise-Cloud mit Datenresidenz durch Migration deines Unternehmens auf GHE.com
  • bestimmte Funktionen auf GitHub.com adaptieren, wie z. B. Enterprise Managed Users oder neue Abrechnungsmodelle, indem du zwischen Unternehmen auf GitHub.com migrierst.
  • Profitiere von einer vereinfachten Administration und neuen Funktionen, indem du von GitHub Enterprise Server zu GitHub Enterprise Cloud migrierst.

Wenn deine Migrationsquelle ein Konto auf GitHub.com ist, kannst du einzelne Repositories zwischen Organisationen oder ganze Organisationen zwischen Unternehmen migrieren. Wenn deine Migrationsquelle GitHub Enterprise Server ist, kannst du einzelne Repositories migrieren.

Die Daten, die GitHub Enterprise Importer übertragen werden, hängen von der Quelle der Migration ab und davon, ob Sie ein Repository oder eine Organisation übertragen.

Überlegungen für Migrationen zu GitHub Enterprise Cloud

Bevor du GitHub Enterprise Importer verwendest, solltest du die folgenden Punkte beachten:

  • Wenn du bereits GitHub Enterprise Cloud verwendest: Ein GitHub Enterprise Plan berechtigt dich zu einer Bereitstellung von GitHub Enterprise Cloud.

    Wenn du z.B. bereits GitHub.com verwendest und zusätzlich von GitHub Enterprise Server auf GHE.com migrieren möchtest, wird deine Nutzung für beides nicht durch einen einzigen Plan abgedeckt.

  • Wenn du zu Enterprise Managed Users migrierst: Du musst dich mit einem Anbieter für Identitätsmanagement zusammenschließen, um Benutzerkonten zu verwalten. Erkundige dich vorher, inwieweit dein Identitätsanbieter unterstützt wird. Weitere Informationen findest du unter Informationen zu Enterprise Managed Users.

  • Wenn du von GitHub Enterprise Server migrierst: Beachte, dass GitHub für bestimmte Aktionen Limits anwendet, die auf GitHub Enterprise Server standardmäßig deaktiviert sind. Weitere Informationen findest du unter Ratenbegrenzungen für die REST-API.

  • Wenn du auf GitHub Enterprise-Cloud mit Datenresidenz migrierst: Sei dir bewusst, dass bestimmte Funktionen nicht verfügbar sind und einige Funktionen eine andere oder zusätzliche Konfiguration erfordern. Weitere Informationen findest du unter Übersicht der Funktionen für GitHub Enterprise Cloud mit Datenresidenz.

Daten, die von GitHub Enterprise Server übertragen werden

Zum Migrieren von GitHub Enterprise Server (GHES) benötigst du GHES ab Version 3.4.1. Die übertragene Daten hängen von der verwendeten Version ab.

ElementGHES 3.4.1 oder höherGHES 3.5.0 oder höher
Git-Quelle (einschließlich Commitverlauf)
Pull Requests
Probleme
Meilensteine
Wikis
GitHub Actions-Workflows
Commit-Kommentare
Webhooks (müssen nach deiner Migration wieder aktiviert werden, siehe Webhooks aktivieren)
Branchschutz
GitHub Pages-Einstellungen
Benutzerverlauf für die oben genannten Daten
Anhänge (siehe Anfügen von Dateien)
Releases

Je nach GHES-Version gelten unterschiedliche Größenbeschränkungen pro Repository für das komprimierte Archiv.

BegrenzungGHES mit einer niedrigeren Version als 3.8.0GHES 3.8.x-3.11.xGHES 3.12.xGHES 3.13.0 oder höher
Git-Quelle2 GiB10GiB20GiB40 GiB (Public Preview)
Metadaten2 GiB10GiB20GiB40 GiB (Public Preview)

Nicht migrierte Daten

Derzeit werden die folgenden Daten nicht migriert.

  • Überwachungsprotokolle
  • Code scanning-Ergebnisse
  • Codespaces-Geheimnisse
  • Überprüfungen des Commitstatus
  • Dependabot-Warnungen
  • Dependabot-Geheimnisse
  • Diskussionen auf Repositoryebene
  • Bearbeiten des Verlaufs von Issuekommentaren und Pull Request-Kommentaren
  • Forken von Beziehungen zwischen Repositorys (siehe Informationen zu Forks)
  • GitHub Actions-Geheimnisse, Variablen, Umgebungen, selbstgehostete Runner, größerer Runners, Workflowartefakte oder Workflowausführungsverlauf
  • GitHub-Apps und GitHub-App-Installationen
  • Git LFS-Objekte und große Binärdateien (Repositorys mit Git LFS werden weiterhin unterstützt. Weitere Informationen findest du unter Einschränkungen von GitHub Enterprise Importer).
  • Verknüpfungen von Commits zu Pull Requests, die mit einem Rebase zusammengeführt wurden
  • Pakete in GitHub Packages
  • Projects (die neue Benutzeroberfläche für Projekte)
  • Verweise zwischen Pull Requests und Issues in verschiedenen Repositorys (siehe Automatisch verlinkte Verweise und URLs)
  • Korrekturstatus von secret scanning-Ergebnissen
  • Repositorys im Besitz von Benutzerkonten
  • Repositoryaktivitätsfeed
  • Repositoryeigenschaften
  • Repositorysterne
  • Repositorywatcher
  • RuleSets
  • Unterprobleme (siehe Informationen zu Issues)
  • Tagschutzregeln
  • Benutzerzugriff auf das Repository
  • Benutzerprofile, SSH-Schlüssel, Signaturschlüssel oder personal access tokens
  • Webhook-Geheimnisse
  • Teams
  • Benutzer- oder Teamzugriff auf das Repository
  • Repositoryeinstellungen für Pull Requests

Branchschutz

Für den Branchschutz werden die angegebenen Regeln auf einen bestimmten Branchnamen oder ein Branchnamenmuster angewandt. Weitere Informationen finden Sie unter Informationen zu geschützten Branches.

Branchschutzmechanismen werden immer migriert, bestimmte Regeln aber nicht. Die folgenden Branchschutzregeln werden nicht migriert.

  • Zulassen, dass bestimmte Akteure erforderliche Pull Requests umgehen können
  • Erzwingen der Genehmigung des neuesten Pushs
  • Erfordern erfolgreicher Bereitstellungen vor dem Mergen
  • Sperren eines Branches
  • Einschränken von Pushvorgängen, die übereinstimmende Branches erstellen
  • Erlauben erzwungener Pushes

Außerdem gelten die folgenden Einschränkungen:

  • Wenn du mit einer Branchschutzregel optional Personen, Teams oder Apps angeben kannst, die von der Regel ausgenommen sind (z. B. „Einschränken, wer Pull Request Reviews verwerfen kann“), werden die Ausnahmen nicht migriert.
  • Wenn die Regel „Erzwingen von Pushvorgängen zulassen“ im Modus „Angeben, wer Push erzwingen kann“ aktiviert ist, wird die Regel nicht migriert.

Daten, die von GitHub.com migriert werden

Wenn deine Migrationsquelle ein Konto auf GitHub.com ist, kannst du einzelne Repositories zwischen Organisationen oder ganze Organisationen zwischen Unternehmen migrieren.

Migrierte Daten für eine Organisation

Wenn du eine Organisation migrierst, wird im Zielunternehmenskonto eine neue Organisation erstellt. Anschließend werden die folgenden Daten zur neuen Organisation migriert.

  • Teams
  • Repositorys
  • Teamzugriff auf Repositorys
  • Mitgliedsberechtigungen
  • Webhooks auf Organisationsebene (müssen nach deiner Migration wieder aktiviert werden, siehe Webhooks aktivieren)
  • Standardbranchname für neue Repositorys, die in der Organisation erstellt werden

Alle Repositorys werden mit privater Sichtbarkeit migriert. Wenn du die Sichtbarkeit eines Repositorys auf öffentlich oder intern festlegen möchtest, kannst du dies nach der Migration auf der Benutzeroberfläche oder mithilfe der API durchführen.

Die Teammitgliedschaft wird nicht migriert. Du musst den migrierten Teams nach der Migration Mitglieder hinzufügen. Weitere Informationen finden Sie unter Übersicht über die Migration zwischen GitHub-Produkten.

Hinweis

Verweise auf Teams, z. B. @octo-org/octo-team, werden im Rahmen einer Organisationsmigration nicht aktualisiert. Dies kann zu Problemen in der Zielorganisation führen, da z. B. CODEOWNERS-Dateien nicht wie erwartet funktionieren. Weitere Informationen darüber, wie du diese Probleme verhindern und lösen kannst, findest du unter Behandeln von Problemen bei der Migration mit GitHub Enterprise Importer.

Migrierte Daten für ein Repository

Wenn du ein Repository direkt oder im Rahmen einer Organisationsmigration migrierst, werden nur die folgenden Daten migriert.

  • Git-Quelle (einschließlich Commitverlauf)
  • Pull Requests
  • Probleme
  • Meilensteine
  • Wikis (mit Ausnahme von Anlagen)
  • GitHub Actions-Workflows
  • Commit-Kommentare
  • Aktive Webhooks (müssen nach deiner Migration wieder aktiviert werden, siehe Webhooks aktivieren)
  • Repositorythemen
  • Repositoryeinstellungen
    • Branch-Protections (siehe Branch-Protections für weitere Details)
    • GitHub Pages-Einstellungen
    • Automatisch verknüpfte Verweise
    • Pull Request-Einstellungen
      • Automatisches Löschen von Headbranches
      • Zulassen der automatischen Zusammenführung
      • Zulassen von Mergecommits (Einstellung der Commitnachricht wird auf die Standardnachricht zurückgesetzt)
      • Zulassen von Squashmerging (Einstellung der Commitnachricht wird auf die Standardnachricht zurückgesetzt)
      • Zulassen von Rebasemerging
  • Releases (bis zu 10 GiB pro Repository)
  • Benutzerverlauf für die oben genannten Daten
  • Anhänge (siehe Anfügen von Dateien)

Nicht migrierte Daten

Derzeit werden die folgenden Daten nicht migriert.

  • Überwachungsprotokolle
  • Code scanning-Ergebnisse
  • Codespaces-Geheimnisse
  • Überprüfungen des Commitstatus
  • Dependabot-Warnungen
  • Dependabot-Geheimnisse
  • Diskussionen auf Repositoryebene
  • Bearbeiten des Verlaufs von Issuekommentaren und Pull Request-Kommentaren
  • Forken von Beziehungen zwischen Repositorys (siehe Informationen zu Forks)
  • GitHub Actions-Geheimnisse, Variablen, Umgebungen, selbstgehostete Runner, größerer Runners, Workflowartefakte oder Workflowausführungsverlauf
  • GitHub-Apps und GitHub-App-Installationen
  • Git LFS-Objekte und große Binärdateien (Repositorys mit Git LFS werden weiterhin unterstützt. Weitere Informationen findest du unter Einschränkungen von GitHub Enterprise Importer).
  • Verknüpfungen von Commits zu Pull Requests, die mit einem Rebase zusammengeführt wurden
  • Pakete in GitHub Packages
  • Projects (die neue Benutzeroberfläche für Projekte)
  • Verweise zwischen Pull Requests und Issues in verschiedenen Repositorys (siehe Automatisch verlinkte Verweise und URLs)
  • Korrekturstatus von secret scanning-Ergebnissen
  • Repositorys im Besitz von Benutzerkonten
  • Repositoryaktivitätsfeed
  • Repositoryeigenschaften
  • Repositorysterne
  • Repositorywatcher
  • RuleSets
  • Unterprobleme (siehe Informationen zu Issues)
  • Tagschutzregeln
  • Benutzerzugriff auf das Repository
  • Benutzerprofile, SSH-Schlüssel, Signaturschlüssel oder personal access tokens
  • Webhook-Geheimnisse

Wenn du ein Repository direkt migrierst, werden Teams und der Teamzugriff auf Repositorys nicht migriert.

Branchschutz

Für den Branchschutz werden die angegebenen Regeln auf einen bestimmten Branchnamen oder ein Branchnamenmuster angewandt. Weitere Informationen finden Sie unter Informationen zu geschützten Branches.

Branchschutzmechanismen werden immer migriert, bestimmte Regeln aber nicht. Die folgenden Branchschutzregeln werden nicht migriert.

  • Zulassen, dass bestimmte Akteure erforderliche Pull Requests umgehen können
  • Erzwingen der Genehmigung des neuesten Pushs
  • Erfordern erfolgreicher Bereitstellungen vor dem Mergen
  • Sperren eines Branches
  • Einschränken von Pushvorgängen, die übereinstimmende Branches erstellen
  • Erlauben erzwungener Pushes

Außerdem gelten die folgenden Einschränkungen:

  • Wenn du mit einer Branchschutzregel optional Personen, Teams oder Apps angeben kannst, die von der Regel ausgenommen sind (z. B. „Einschränken, wer Pull Request Reviews verwerfen kann“), werden die Ausnahmen nicht migriert.
  • Wenn die Regel „Erzwingen von Pushvorgängen zulassen“ im Modus „Angeben, wer Push erzwingen kann“ aktiviert ist, wird die Regel nicht migriert.

Einschränkungen bei migrierten Daten

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

Grenzwerte auf 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.

  •         **Grenzwert von 255 Byte für Git-Verweise:** Kein einzelner [Git-Verweis](https://git-scm.com/book/en/v2/Git-Internals-Git-References) (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](https://en.wikipedia.org/wiki/ASCII) 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 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äge die Verwendung von Git LFS zum Speichern großer Dateien. Weitere Informationen finden Sie unter [AUTOTITLE](/repositories/working-with-files/managing-large-files).

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.
  •           **40 GiB Limit für Metadaten (öffentliche Vorschau):** Die Importer können keine Repositories mit mehr als 40 GiB an 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.
  • Grenzwert von 400 MB für die Dateigröße: Beim Migrieren eines Repositorys mit GitHub Enterprise Importer darf keine einzelne Datei in deinem Git-Repository größer als 400 MB sein. Erwäge die Verwendung von Git LFS zum Speichern großer Dateien. Weitere Informationen finden Sie unter Große Dateien verwalten.
  • 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 finden Sie 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 finden Sie unter Freigeben von Mannequins für GitHub Enterprise Importer.

Erste Schritte

Vor der Migration zwischen GitHub-Produkten 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 findest du unter Übersicht über die Migration zwischen GitHub-Produkten.