Informationen zu Migrationen zwischen GitHub-Produkten

Informationen zu Migrationen zwischen GitHub-Produkten

Mit GitHub Enterprise Importer kannst du Daten von GitHub Enterprise Server zu GitHub Enterprise Cloud oder von GitHub.com zu einem anderen Konto auf GitHub Enterprise Cloud migrieren.

Mit GitHub Enterprise Importer hat dein Unternehmen beispielsweise folgende Möglichkeiten:

• Einführen von GitHub Enterprise-Cloud mit Datenresidenz durch die Migration deines Unternehmens zu GHE.com
• Übernehmen bestimmter Features auf GitHub.com, z. B. von Enterprise Managed Users oder von neuen Abrechnungsmodellen, durch die Migration zwischen Unternehmen auf GitHub.com
• Profitieren von einer vereinfachten Verwaltung und von neuen Features durch die Migration von GitHub Enterprise Server zu GitHub Enterprise Cloud

Wenn deine Migrationsquelle ein Konto auf GitHub.com ist, kannst du einzelne Repositorys zwischen Organisationen oder ganze Organisationen zwischen Unternehmen migrieren. Wenn GitHub Enterprise Server deine Migrationsquelle ist, kannst du einzelne Repositorys 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.

Hinweise zu Migrationen zu GitHub Enterprise Cloud

Bei Verwendung von GitHub Enterprise Importer, ist Folgendes zu beachten:

• Wenn du GitHub Enterprise Cloud bereits verwendest: Mit einem GitHub Enterprise-Plan hast du die Berechtigung für eine Bereitstellung von GitHub Enterprise Cloud.

  Wenn du beispielsweise GitHub.com bereits verwendest und du zudem von GitHub Enterprise Server zu GHE.com migrieren möchtest, ist die Nutzung von beidem durch einen einzelnen Plan nicht abgedeckt.

• Wenn du zu Enterprise Managed Users migrierst: Du musst zur Verwaltung von Benutzerkonten einen Identitätsanbieter einbinden. Informiere dich vor Beginn über die Supportebene für deinen Identitätsanbieter. Weitere Informationen finden Sie unter Informationen zu Enterprise Managed Users.

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

• Wenn du zu GitHub Enterprise-Cloud mit Datenresidenz migrierst: Beachte, dass bestimmte Features nicht verfügbar sind und dass für einige Features andere oder weitere Konfigurationsschritte erforderlich sind. Weitere Informationen finden Sie unter Featureübersicht über GitHub Enterprise Cloud mit Datenresidenz.

Daten, die von GitHub Enterprise Server übertragen werden

git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror

git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror

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.

Je nach GHES-Version gelten unterschiedliche Größengrenzwerte pro Repository.

Nicht migrierte Daten

Derzeit werden die folgenden Daten nicht migriert.

• Überwachungsprotokolle
• Code scanning-Ergebnisse
• Ü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, Selfhost-Runner, größerer Runners oder Workflow-Ausfü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).
• Pakete in GitHub Packages
• Projekte (klassisch) auf Organisationsebene
• 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
• Repository-Eigenschaften
• Repositorysterne
• Repositorywatcher
• RuleSets
• Tagschutzregeln
• 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 findest du 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 Repositorys 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 der Migration erneut aktiviert werden, siehe „Aktivieren von Webhooks“)
• 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 findest du unter Übersicht über die Migration zwischen GitHub-Produkten.

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 der Migration erneut aktiviert werden, siehe „Aktivieren von Webhooks“)
• Repositorythemen
• Repositoryeinstellungen
  • Branchschutzmechanismen (weitere Informationen findest du unter Branchschutz)
  • GitHub Pages-Einstellungen
  • Automatisch verknüpfte Verweise
  • GitHub Advanced Security-Einstellungen
  • 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 GB pro Repository)
• Benutzerverlauf für die oben genannten Daten
• Anlagen (siehe „Anfügen von Dateien“)

Nicht migrierte Daten

Derzeit werden die folgenden Daten nicht migriert.

• Codespaces-Geheimnisse * Überwachungsprotokolle
• Code scanning-Ergebnisse
• Ü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, Selfhost-Runner, größerer Runners oder Workflow-Ausfü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).
• Pakete in GitHub Packages
• Projekte (klassisch) auf Organisationsebene
• 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
• Repository-Eigenschaften
• Repositorysterne
• Repositorywatcher
• RuleSets
• Tagschutzregeln
• Benutzerprofile, SSH-Schlüssel, Signaturschlüssel oder personal access tokens
• Webhook-Geheimnisse
• Benutzerzugriff auf das Repository

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 findest du 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

• 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

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 finden Sie unter „Übersicht über die Migration zwischen GitHub-Produkten“.