Migrationsunterstützung für GitHub Enterprise Importer

Informationen zur Migrationsunterstützung für GitHub Enterprise Importer

GitHub Enterprise Importer kann aus allen unterstützten Quellen zu GitHub Enterprise Cloud migrieren. Die in einer Migration enthaltenen Daten hängen von der Quelle ab.

GitHub Enterprise Importer unterstützt die Migration zu GitHub Enterprise Cloud aus den folgenden Quellen.

• Azure DevOps-Cloud (ADO)
• Bitbucket Server und Bitbucket Data Center 5.14 und höher
• GitHub.com
• GitHub Enterprise Server (GHES) 3.4.1 und höher

Während der Betaphase gelten für alle Quellen einige bekannte Einschränkungen für Importer.

Azure DevOps-Migrationsunterstützung

Wenn deine Migrationsquelle Azure DevOps ist, kannst du Repositorys 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.

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
• Branchschutzmechanismen für das Repository (ohne Branchschutzmechanismen im Benutzerbereich)

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

Unterstützung der Migration von Bitbucket Server

Die Migration von Bitbucket Server wird nur für Bitbucket Server oder Bitbucket Data Center ab Version 5.14 unterstützt.

Wenn du als Migrationsquelle Bitbucket Server verwendest, kannst du Repositorys migrieren. Derzeit wird nur die Migration der folgenden Repositorydaten von Bitbucket Server zu GitHub Enterprise Cloud unterstützt.

• Git-Quelle (einschließlich Commitverlauf)
• Pull Requests (Kommentare, Pull Request-Reviews, Pull Request-Reviewkommentare auf Datei- und Zeilenebene, erforderliche Reviewer und Anlagen eingeschlossen)

Derzeit werden die folgenden Daten nicht migriert.

• Persönliche Repositorys im Besitz von Benutzern
• Branchberechtigungen
• Commit-Kommentare
• Repositoryeinstellungen

GitHub Enterprise Importer migriert keine CI-Pipelines von Bitbucket Server.

GitHub.com-Migrationsunterstützung

Wenn GitHub.com deine Migrationsquelle ist, kannst du einzelne Repositorys oder ganze Organisationen migrieren.

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
• 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 Migrieren zwischen GitHub-Produkten mit GitHub Enterprise Importer.

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
• Projekte (klassisch) auf Repositoryebene
• GitHub Actions-Workflows
• Commit-Kommentare
• Aktive 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

Derzeit werden die folgenden Daten nicht migriert.

• Alle Projects (die neue Benutzeroberfläche für Projekte)
• 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 Codespaces-Geheimnisse
• 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
• 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
• Repositoryeigenschaften (öffentliche Betaversion)
• 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.

GitHub Enterprise Server-Migrationsunterstützung

Wenn GitHub Enterprise Server deine Migrationsquelle ist, kannst du Repositorys migrieren.

Zum Migrieren von GitHub Enterprise Server (GHES) benötigst du GHES ab Version 3.4.1.

Element	GHES 3.4.1 oder höher	GHES 3.5.0 oder höher
Git-Quelle (einschließlich Commitverlauf)	X	X
Pull Requests	X	X
Probleme	X	X
Meilensteine	X	X
Wikis	X	X
Projekte (klassisch) auf Repositoryebene	X	X
GitHub Actions-Workflows	X	X
Commit-Kommentare	X	X
Aktive Webhooks	X	X
Branchschutz	X	X
GitHub Pages-Einstellungen	X	X
Benutzerverlauf für die oben genannten Daten	X	X
Releases
X

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

Derzeit werden die folgenden Daten nicht migriert.

• Alle Projects (die neue Benutzeroberfläche für Projekte)
• 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 Codespaces-Geheimnisse
• 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
• 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
• Repositoryeigenschaften (öffentliche Betaversion)
• 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

Einschränkungen

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 die Größe deines Repositorys zu überprüfen, verwendest du das Tool git-sizer, und überprüfst die Gesamtgröße der Blobs.
• 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 Migrieren zwischen GitHub-Produkten mit GitHub Enterprise Importer.
• 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.