Informationen zu Migrationen zwischen den GitHub-Produkten mit GitHub Enterprise Importer

Erfahren Sie, welche Daten GitHub Enterprise Importer zwischen GitHub Produkten migriert werden können.

In diesem Artikel

Informationen zu Migrationen zwischen GitHub Produkten

Mit GitHub Enterprise Importer können Sie Daten von GitHub Enterprise Server nach GitHub Enterprise Cloud migrieren oder Daten von GitHub.com zu einem anderen Konto auf GitHub Enterprise Cloud migrieren.

Wenn Ihre Migrationsquelle ein Konto GitHub.comist, können Sie einzelne Repositorys zwischen Organisationen migrieren oder ganze Organisationen zwischen Unternehmen migrieren. Wenn Ihre Migrationsquelle lautet GitHub Enterprise Server, können Sie einzelne Repositorys migrieren.

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

Wenn die Zielorganisation oder das Unternehmen Regelsätze aktiviert hat, kann der Verlauf des migrierten Repositorys gegen diese Regeln verstoßen. Um die Migration zuzulassen, ohne Ihre Rulesets zu deaktivieren, fügen Sie „Repository-Migrationen” der Ausnahmeliste für jedes anwendbare Ruleset hinzu. Diese Umgehung gilt nur während der Migration. Sobald dies abgeschlossen ist, werden Regelsätze auf alle neuen Beiträge angewendet.

So konfigurieren Sie die Umgehung:

  1. Navigieren Sie zu jedem Unternehmens- oder Organisationsregelsatz.
  2. Klicken Sie im Abschnitt "Umgehungsliste" auf "Umgehungsumgehung hinzufügen".
  3. Wählen Sie Repository-Migrationen aus.

Weitere Informationen findest du unter Erstellen von Regelsätzen für Repositorys in deiner Organisation und Festlegen von Regelsatzumgehungen für Repositorymigrationen.

Daten, die migriert wurden GitHub Enterprise Server

Um von GitHub Enterprise Server (GHES) zu migrieren, müssen Sie über GHES Version 3.4.1 oder höher verfügen. 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 Arbeitsabläufe | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  |

Commit-Kommentare | | | Webhooks (müssen nach deiner Migration wieder aktiviert werden, siehe Webhooks aktivieren) | | | Branchschutz | | |

          GitHub Pages Einstellungen | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  |

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 geheime Schlüssel, Variablen, Umgebungen, selbstgehostete Runner, größerer Runners, Workflow-Artefakte oder Workflow-Ausführungsverlauf
  • GitHub Apps und GitHub App-Installationen
  • Git LFS Objekte und große Binärdateien (Repositories Git LFS werden weiterhin unterstützt, siehe Einschränkungen von GitHub Enterprise Importer)
  • Verknüpfungen von Commits zu Pull Requests, die mit einem Rebase zusammengeführt wurden
  • Erwähnungen von Benutzern, Teams und Organisationen in Pull-Request-, Issue-, Release- und Kommentartexten (der ursprünglich erwähnte Benutzername wird beibehalten)
  • Pakete in GitHub Packages
  • Projects (die neue Projekterfahrung)
  • Bezüge zwischen Pull-Requests und Issues in verschiedenen Repositories (siehe Automatisch verlinkte Verweise und URLs)
  • Behebungsstatus von secret scanning Ergebnissen
  • Repositorys im Besitz von Benutzerkonten
  • Repositoryaktivitätsfeed
  • Repositoryeigenschaften und benutzerdefinierte Eigenschaften (siehe Benutzerdefinierte Eigenschaften)
  • Repositorysterne
  • Repositorywatcher
  • RuleSets
  • Unterprobleme (siehe Informationen zu Problemen)
  • 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 wurden

Wenn Ihre Migrationsquelle ein Konto GitHub.comist, können Sie einzelne Repositorys zwischen Organisationen migrieren 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 zum Verhindern und Beheben dieser Probleme finden Sie unter [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/troubleshooting-your-migration-with-github-enterprise-importer#team-references-are-broken-after-an-organization-migration).

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 Arbeitsabläufe
  • 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 geheime Schlüssel, Variablen, Umgebungen, selbstgehostete Runner, größerer Runners, Workflow-Artefakte oder Workflow-Ausführungsverlauf
  • GitHub Apps und GitHub App-Installationen
  • Git LFS Objekte und große Binärdateien (Repositories Git LFS werden weiterhin unterstützt, siehe Einschränkungen von GitHub Enterprise Importer)
  • Verknüpfungen von Commits zu Pull Requests, die mit einem Rebase zusammengeführt wurden
  • Erwähnungen von Benutzern, Teams und Organisationen in Pull-Request-, Issue-, Release- und Kommentartexten (der ursprünglich erwähnte Benutzername wird beibehalten)
  • Pakete in GitHub Packages
  • Projects (die neue Projekterfahrung)
  • Bezüge zwischen Pull-Requests und Issues in verschiedenen Repositories (siehe Automatisch verlinkte Verweise und URLs)
  • Behebungsstatus von secret scanning Ergebnissen
  • Repositorys im Besitz von Benutzerkonten
  • Repositoryaktivitätsfeed
  • Repositoryeigenschaften und benutzerdefinierte Eigenschaften (siehe Benutzerdefinierte Eigenschaften)
  • Repositorysterne
  • Repositorywatcher
  • RuleSets
  • Unterprobleme (siehe Informationen zu Problemen)
  • 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 (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 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 Große Dateien verwalten.

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-Grenzwert für Metadaten (öffentliche Vorschau): Die Importer Repositorys können nicht mit mehr als 40 GiB-Metadaten migriert werden. 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 migrate-repo des Befehls --skip-releases 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

Bevor Sie zwischen GitHub Produkten migrieren, sollten Sie planen, wie Sie Ihre Migration ausführen. 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.