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 findest du 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 findest du 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 findest du unter Featureübersicht über 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.

Artikel	GHES 3.4.1 oder höher	GHES 3.5.0 oder höher
Git-Quelle (einschließlich Commitverlauf)
Pullanforderungen
Probleme
Meilensteine
Wikis
GitHub Actions-Workflows
Commit-Kommentare
Webhooks (müssen nach der Migration erneut aktiviert werden, siehe Aktivieren von Webhooks)
Branchschutz
GitHub Pages-Einstellungen
Benutzerverlauf für die oben genannten Daten
Anlagen (siehe Anfügen von Dateien)
Releases

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

Begrenzung	GHES 3.8.0 oder früher	GHES 3.8.0 oder höher
Git-Quelle	2GB	10GB
Metadaten	2GB	10GB

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).
• Verknüpfungen von Commits zu Pull Requests, die mit einem Rebase zusammengeführt wurden
• 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
• Repositoryaktivitätsfeed
• Repositoryeigenschaften
• 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 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 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 finden Sie 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
  • 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).
• Verknüpfungen von Commits zu Pull Requests, die mit einem Rebase zusammengeführt wurden
• 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
• Repositoryaktivitätsfeed
• Repositoryeigenschaften
• 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 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

• 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.
• Grenzwert von 100 MB für die Dateigröße: Nach Abschluss der Migration darf keine einzelne Datei in deinem Git-Repository größer als 100 MB sein. Während der Repositorymigration wird dieser Grenzwert auf 400 MB erhöht. Erwäge die Verwendung von Git LFS zum Speichern großer Dateien. Weitere Informationen finden Sie unter Große Dateien verwalten.

Einschränkungen von GitHub Enterprise Importer

• Grenzwert für die Größe von 40 GB für ein Git-Repository (beta): 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 40 GB für Metadaten (beta): Importer kann keine Repositorys mit mehr als 40 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.
• 400 MB file size limit: When migrating a repository with GitHub Enterprise Importer, no single file in your Git repository can be larger than 400 MB. Consider using Git LFS for storing large files. For more information, see Große Dateien verwalten.
• Git LFS objects not migrated: The Importer can migrate repositories that use Git LFS, but the LFS objects themselves will not be migrated. They can be pushed to your migration destination as a follow-up task after the migration is complete. For more information, see Ein Repository duplizieren.
• Follow-up tasks required: When migrating between GitHub products, certain settings are not migrated and must be reconfigured in the new repository. For a list of follow-up tasks you'll need to complete after each migration, see Übersicht über die Migration zwischen GitHub-Produkten.
• Delayed code search functionality: Re-indexing the search index can take a few hours after a repository is migrated, and code searches may return unexpected results until re-indexing is complete.
• Rulesets configured for your organization can cause migrations to fail: For example, if you configured a rule that requires email addresses for commit authors to end with @monalisa.cat, and the repository you're migrating contains commits that don't comply with this rule, your migration will fail. For more information about rulesets, see Informationen zu Regelsätzen.
• Mannequin content might not be searchable: Mannequins are placeholder users to which imported content (such as issues, pull requests, comments, etc.) is associated. When you search for content associated with a mannequin, such as assigned issues, the issues may not be found. Once a mannequin is reclaimed, the content should be found via the new owner. For more information, see 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.