Migrieren von Repositorys von GitHub.com zu GitHub Enterprise Cloud

Du kannst Repositorys von GitHub.com zu GitHub Enterprise Cloud migrieren, indem du die GitHub CLI oder die GraphQL-API verwendest.

Tool navigation

In diesem Artikel

Informationen über Repository-Migrationsvorgänge mit GitHub Enterprise Importer

Migrationen zu GitHub Enterprise Cloud umfassen sowohl Kontenwechsel auf GitHub.com als auch, wenn du Datenresidenz einführst, Migrationen zur Unterdomäne deines Unternehmens auf GHE.com.

Du kannst deine Migration entweder mit der GitHub CLI oder mit der API ausführen.

Die GitHub CLI vereinfacht den Migrationsprozess und wird für die meisten Kundinnen empfohlen. Fortgeschrittene Kundinnen, die viele Anpassungen vornehmen müssen, können die API verwenden, um eigene Integrationen mit dem GitHub Enterprise Importer zu erstellen.

Um Anweisungen für die Verwendung der API anzuzeigen, verwendest du den Toolumschalter oben auf der Seite.
Um Anweisungen zur Verwendung der GitHub CLI anzuzeigen, verwendest du den Toolumschalter oben auf der Seite.

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 finden Sie unter Erstellen von Regelsätzen für Repositorys in deiner Organisation.

Voraussetzungen

  • Es wird dringend empfohlen, einen Testlauf deiner Migration durchzuführen und die Produktionsmigration bald danach abzuschließen. Weitere Informationen zu Testläufen findest du unter Übersicht über die Migration zwischen GitHub-Produkten.
  • Stellen Sie sicher, dass Sie die zu migrierenden Daten und die bekannten Supportbeschränkungen des Importer verstehen. Weitere Informationen findest du unter Informationen zu Migrationen zwischen GitHub-Produkten.
  • Es ist zwar nicht erforderlich, die Arbeit während der Produktionsmigration zu unterbrechen, es wird aber empfohlen. Der Importer unterstützt keine Deltamigrationen, sodass Änderungen, die während der Migration vorgenommen werden, nicht migriert werden. Wenn du dich dafür entscheidest, die Arbeit während der Produktionsmigration nicht zu unterbrechen, musst du diese Änderungen manuell migrieren.
  • Sowohl in der Quell- als auch in der Zielorganisation musst du entweder Organisationsbesitzer*in sein, oder dir muss die Migrationsrolle zugewiesen sein. Weitere Informationen finden Sie unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.

Schritt 0: Vorbereiten der Verwendung der GraphQL-API von GitHub

Um GraphQL-Abfragen zu erstellen, musst du eigene Skripts schreiben oder einen HTTP-Client wie Insomnia verwenden.

Weitere Informationen zu den ersten Schritten mit der GitHub-GraphQL-API, einschließlich der Authentifizierung, findest du unter Erstellen von Aufrufen mit GraphQL.

Du sendest alle GraphQL-Abfragen an das Ziel deiner Migration. Stelle bei der Migration zu GitHub Enterprise-Cloud mit Datenresidenz sicher, dass du Abfragen an den Endpunkt für die Unterdomäne für GHE.com sendest.

Schritt 1: Holen Sie sich das ownerId für Ihr Migrationsziel

Verwende als Organisationsbesitzer*in in GitHub Enterprise Cloud die Abfrage GetOrgInfo, um die ownerId (auch als Organisations-ID bezeichnet) für die Organisation zurückzugeben, der du den Besitz der migrierten Repositorys zuordnen möchtest. Du benötigst die ownerId, um das Migrationsziel anzugeben.

Abfrage GetOrgInfo

query(
  $login: String!
){
  organization (login: $login)
  {
    login
    id
    name
    databaseId
  }
}
AbfragevariableBeschreibung
loginName deiner Organisation.

Antwort von GetOrgInfo

{
  "data": {
    "organization": {
      "login": "Octo",
      "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
      "name": "Octo-org",
      "databaseId": 5610
    }
  }
}

In diesem Beispiel ist MDEyOk9yZ2FuaXphdGlvbjU2MTA= die Organisations-ID oder die ownerId, die du im nächsten Schritt verwendest.

Schritt 2: Ermitteln der Migrationsquelle

Einführung in die Identifizierung der Migrationsquelle im Enterprise-Migrationstool

Deine Migrationsquelle ist eine Organisation auf GitHub.com.

          `createMigrationSource`-Veränderung

mutation createMigrationSource($name: String!, $ownerId: ID!) {
  createMigrationSource(input: {name: $name, url: "https://github.com", ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
    migrationSource {
      id
      name
      url
      type
    }
  }
}

Hinweis

Stelle sicher, dass du GITHUB_ARCHIVE für type verwendest.

          `createMigrationSource` Antwort

{
  "data": {
    "createMigrationSource": {
      "migrationSource": {
        "id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
        "name": "GitHub.com Source",
        "url": "https://github.com",
        "type": "GITHUB_SOURCE"
      }
    }
  }
}

In diesem Beispiel ist MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA die ID der Migrationsquelle, die du im nächsten Schritt verwendest.

Schritt 3: Beginnen Sie mit der Repository-Migration

          `startRepositoryMigration` Mutation

mutation startRepositoryMigration (
  $sourceId: ID!,
  $ownerId: ID!,
  $sourceRepositoryUrl: URI!,
  $repositoryName: String!,
  $continueOnError: Boolean!,
  $accessToken: String!,
  $githubPat: String!,
  $targetRepoVisibility: String!
){
  startRepositoryMigration( input: {
    sourceId: $sourceId,
    ownerId: $ownerId,
    repositoryName: $repositoryName,
    continueOnError: $continueOnError,
    accessToken: $accessToken,
    githubPat: $githubPat,
    targetRepoVisibility: $targetRepoVisibility
    sourceRepositoryUrl: $sourceRepositoryUrl,
  }) {
    repositoryMigration {
      id
      migrationSource {
        id
        name
        type
      }
      sourceUrl
    }
  }
}
AbfragevariableBeschreibung
sourceIdDie id deiner Migrationsquelle, die von der createMigrationSource-Mutation zurückgegeben wurde.
ownerIdDie Organisations-ID deiner Organisation in GitHub Enterprise Cloud.
repositoryNameEin benutzerdefinierter eindeutiger Repositoryname, der derzeit von keinem deiner Repositorys im Besitz der Organisation auf GitHub Enterprise Cloud verwendet wird. Wenn die Migration abgeschlossen oder beendet wurde, wird ein Fehlerprotokollierungsproblem in diesem Repository erstellt.
continueOnErrorMigrationseinstellung, mit der die Migration fortgesetzt werden kann, wenn Fehler auftreten, die nicht dazu führen, dass die Migration fehlerhaft wird. Muss true oder false sein. Es wird dringend empfohlen continueOnError auf true festzulegen, damit die Migration fortgesetzt wird, es sei denn, der Importer kann die Git-Quelle nicht verschieben oder der Importer hat die Verbindung unterbrochen und kann die Verbindung nicht wiederherstellen, um die Migration abzuschließen.
githubPatDas personal access token für deine Zielorganisation auf GitHub Enterprise Cloud.
accessTokenDas personal access token für deine Quelle.
targetRepoVisibilityDie Sichtbarkeit des neuen Repositorys. Muss private, public oder internal sein. Wenn sie nicht festgelegt wurde, wird dein Repository als privat migriert.
sourceRepositoryUrlDie URL deines Quellrepositorys im Format https://github.com/{organization}/{repository}.

Weitere Informationen zu den Anforderungen für personal access token findest du unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.

Im nächsten Schritt verwendest du die von der startRepositoryMigration-Mutation zurückgegebene Migrations-ID, um den Migrationsstatus zu überprüfen.

Schritt 4: Überprüfen des Migrationsstatus

Um Migrationsfehler zu erkennen und sicherzustellen, dass deine Migration funktioniert, kannst du den Migrationsstatus mithilfe der Abfrage getMigration überprüfen. Du kannst auch den Status mehrerer Migrationsvorgänge mit getMigrations überprüfen.

Die Abfrage getMigration gibt für die Migration einen der folgenden Status zurück: queued, in progress, failed oder completed. Wenn die Migration fehlerhaft war, gibt der Importer einen Grund für den Fehler an.

Abfrage getMigration

query (
  $id: ID!
){
  node( id: $id ) {
    ... on Migration {
      id
      sourceUrl
      migrationSource {
        name
      }
      state
      failureReason
    }
  }
}
AbfragevariableBeschreibung
idDie id deiner Migration, die von der startRepositoryMigration-Mutation zurückgegeben wurde.

Schritt 5: Überprüfen der Migration und des Fehlerprotokolls

Validieren Sie das Migrationsprotokoll

Schritt 1: Installieren der GEI extension of the GitHub CLI

Wenn dies deine erste Migration ist, musst du die GEI extension of the GitHub CLI installieren. Weitere Informationen zur GitHub CLI findest du unter Informationen zu GitHub CLI.

Alternativ können Sie eine eigenständige Binärdatei von der Veröffentlichungsseite für das github/gh-gei-Repository herunterladen. Sie können daraufhin die Binärdatei direkt ohne das gh-Präfix ausführen.

  1. Installiere die GitHub CLI. Installationsanweisungen für GitHub CLI findest du im GitHub CLI-Repository.

    Hinweis

    Du benötigst Version 2.4.0 oder höher der GitHub CLI. Die installierte Version kannst du mit dem Befehl gh --version ermitteln.

  2. Installiere die GEI extension.

    Shell
    gh extension install github/gh-gei

Wenn du Hilfe zur GEI extension benötigst, kannst du immer das Flag --help mit einem Befehl verwenden. Mit gh gei --help listest du z. B. alle verfügbaren Befehle auf, und mit gh gei migrate-repo --help zeigst du alle Optionen an, die für den Befehl migrate-repo verfügbar sind.

Schritt 2: Aktualisieren der GEI extension of the GitHub CLI

Die GEI extension wird wöchentlich aktualisiert. Aktualisieren die Erweiterung, um sicherzustellen, dass du die neueste Version verwendest.

gh extension upgrade github/gh-gei

Schritt 3: Festlegen der Umgebungsvariablen

Bevor du GEI extension zum Migrieren zu GitHub Enterprise Cloud verwenden kannst, musst du personal access token erstellen, die auf die Quell- und Zielorganisationen zugreifen können, und dann die personal access token als Umgebungsvariablen festlegen.

  1. Erstelle ein personal access token (classic) für die Authentifizierung der Zielorganisation auf GitHub Enterprise Cloud, und stelle sicher, dass das Token alle Anforderungen erfüllt. Weitere Informationen finden Sie unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.

  2. Erstelle ein personal access token für die Authentifizierung der Quellorganisation, und stelle außerdem sicher, dass dieses Token alle Anforderungen erfüllt.

  3. Lege Umgebungsvariablen für die personal access token fest, und ersetze in den folgenden Befehlen TOKEN durch die personal access token, die du oben gespeichert hast. Verwende das GH_PAT für die Zielorganisation und das GH_SOURCE_PAT für die Quellorganisation.

    • Wenn du ein Terminal verwendest, führe den Befehl export aus.

      Shell
      export GH_PAT="TOKEN"
export GH_SOURCE_PAT="TOKEN"

    • Wenn du PowerShell verwendest, führe den Befehl $env aus.

      Shell
      $env:GH_PAT="TOKEN"
$env:GH_SOURCE_PAT="TOKEN"

  4. Wenn Sie auf GitHub Enterprise-Cloud mit Datenresidenz migrieren, legen Sie zur Vereinfachung eine Umgebungsvariable für die Basis-API-URL für Ihr Unternehmen fest.

    Stellen Sie sicher, dass Sie SUBDOMAIN durch die Unterdomäne Ihres Unternehmens ersetzen. Wenn die Unterdomäne Ihres Unternehmens beispielsweise "acme" lautet, wäre der Wert von "TARGET_API_URL" "https://api.acme.ghe.com".

    • Wenn du ein Terminal verwendest, führe den Befehl export aus.

      Shell
      export TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"

    • Wenn du PowerShell verwendest, führe den Befehl $env aus.

      Shell
      $env:TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"

    Sie verwenden diese Variable mit der --target-api-url-Option in Befehlen, die Sie mit der GitHub CLI ausführen.

Schritt 4: Generieren eines Migrationsskripts

Der Migrationsskriptgenerator der Unternehmens-Migrationstools verwenden

Wenn du ein einzelnes Repository migrieren möchtest, fahre mit dem nächsten Schritt fort.

Generieren eines Migrationsskripts

Führe den Befehl gh gei generate-script aus, um ein Migrationsskript zu generieren.

Shell
gh gei generate-script --github-source-org SOURCE --github-target-org DESTINATION --output FILENAME

Wenn Sie GEI als eigenständige Binärdatei heruntergeladen haben und nicht als Erweiterung für die GitHub CLI, müssen Sie das generierte Skript aktualisieren, um die Binärdatei anstelle von gh gei auszuführen.

Platzhalter

Ersetze die Platzhalter im obigen Befehl durch die folgenden Werte.

PlatzhalterWert
SOURCEName der Ursprungsorganisation
DESTINATIONName der Zielorganisation
FILENAMEEin Dateiname für das resultierende Migrationsskript

Wenn du das Terminal verwendest, legst du als Erweiterung .ps1 fest, da für das generierte Skript PowerShell ausgeführt werden muss. Du kannst PowerShell für Mac oder Linux installieren.

Zusätzliche Argumente

ArgumentBeschreibung
--target-api-url TARGET-API-URLWenn du zu GHE.com migrierst, füge --target-api-url TARGET-API-URL hinzu, wobei TARGET-API-URL die Basis-API-URL für die Unterdomäne deines Unternehmens ist. Beispiel: https://api.octocorp.ghe.com
--download-migration-logsLade das Migrationsprotokoll für jedes migrierte Repository herunter. Weitere Informationen zu Migrationsprotokollen findest du unter Zugriff auf die Migrationsprotokolle von GitHub Enterprise Importer.

Überprüfen des Migrationsskripts

Bewerten Sie das Migrationsskript im Enterprise-Migrationstool.

Wenn dein Repository mehr als 10 GB Releasedaten enthält, können Releases nicht migriert werden. Verwende das Flag --skip-releases, um das Repository ohne Releases zu migrieren.

Wenn Sie GEI als eigenständige Binärdatei heruntergeladen haben und nicht als Erweiterung für die GitHub CLI, müssen Sie das generierte Skript aktualisieren, um die Binärdatei anstelle von gh gei auszuführen.

Schritt 5: Migrieren von Repositorys

Mit dem Befehl gh gei migrate-repo kannst mehrere Repositorys mit einem Migrationsskript oder einem einzelnen Repository migrieren.

Migrieren mehrerer Repositorys

Migrieren eines einzelnen Repositorys

Verwende den Befehl gh gei migrate-repo, um ein einzelnes Repository zu migrieren.

Shell
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME

Platzhalter

Ersetze die Platzhalter im obigen Befehl durch die folgenden Werte.

PlatzhalterWert
SOURCEName der Ursprungsorganisation
CURRENT-NAMEDer Name des Repositorys, das du migrieren möchtest
DESTINATIONName der Zielorganisation
NEW-NAMEDer Name für das migrierte Repository

Zusätzliche Argumente

ArgumentBeschreibung
--target-api-url TARGET-API-URLWenn du zu GHE.com migrierst, füge --target-api-url TARGET-API-URL hinzu, wobei TARGET-API-URL die Basis-API-URL für die Unterdomäne deines Unternehmens ist. Beispiel: https://api.octocorp.ghe.com
--skip-releasesWenn dein Repository mehr als 10 GB Releasedaten enthält, können Releases nicht migriert werden. Verwende das Flag --skip-releases, um das Repository ohne Releases zu migrieren.
--target-repo-visibility TARGET-VISIBILITYRepositorys werden standardmäßig mit privater Sichtbarkeit migriert. Um die Sichtbarkeit festzulegen, können Sie das Flag --target-repo-visibility hinzufügen und private, public oder internal angeben. Wenn Sie zu Unternehmen mit verwalteten Benutzer*innen migrieren, sind öffentliche Repositorys nicht verfügbar.

Abbrechen der Migration

Wenn Sie eine Migration abbrechen möchten, verwenden Sie den Befehl abort-migration und ersetzen Sie die MIGRATIONS-ID durch die zurückgesendete ID migrate-repo.

Shell
gh gei abort-migration --migration-id MIGRATION-ID

Schritt 6: Überprüfen der Migration und des Fehlerprotokolls