Skip to main content

Diese Version von GitHub Enterprise Server wurde eingestellt am 2024-09-25. Es wird keine Patch-Freigabe vorgenommen, auch nicht für kritische Sicherheitsprobleme. Für bessere Leistung, verbesserte Sicherheit und neue Features aktualisiere auf die neueste Version von GitHub Enterprise Server. Wende dich an den GitHub Enterprise-Support, um Hilfe zum Upgrade zu erhalten.

Migrationsdaten von GitHub.com exportieren

Du kannst Migrationsdaten aus einer Organisation auf GitHub.com mithilfe der API zum Migrieren von Repositorys exportieren und dann ein Migrationsarchiv generieren, das du in eine GitHub Enterprise Server-Instanz importieren kannst.

Vorbereiten der Quellorganisation auf GitHub

  1. Stelle sicher, dass du über Besitzerberechtigungen für die Repositorys der Quellorganisation verfügst.

  2. Generieren eines Zugriffstokens mit den Bereichen repo und admin:org auf GitHub.com.

  3. Erstelle zum Minimieren der Ausfallzeit eine Liste der Repositorys, die Du von der Quellinstanz exportieren möchtest. Du kannst mehrere Repositorys gleichzeitig zu einem Export hinzufügen. verwende dazu eine Textdatei, in der die URL jedes Repositorys in einer separaten Zeile aufgelistet wird.

Exportieren der Repositorys der Organisation

Note

Forkbeziehungen bleiben nach einer Migration nicht bestehen.

Zum Exportieren von Repositorydaten aus GitHub.com verwendest du die Migrations-API.

Die API für Migrationen befindet sich derzeit in einer Vorschauphase, weshalb sich die Endpunkte und Parameter künftig ändern können.

Migrationsarchiv generieren

Note

Das Sperren eines Repositorys verhindert den gesamten Schreibzugriff auf das Repository. Einem gesperrten Repository können keine neuen Teams oder Mitarbeiter zugeordnet werden.

Wenn du eine Testversion ausführst, musst du das Repository nicht sperren. Wenn du Daten aus einem Repository migrierst, das gerade verwendet wird, empfiehlt GitHub die Sperrung des Repositorys. Weitere Informationen findest du unter Informationen zu „ghe-migrator“.

  1. Benachrichtige die Mitglieder deiner Organisation, dass du eine Migration durchführen wirst. Der Export kann entsprechend der Anzahl der zu exportierenden Repositorys mehrere Minuten dauern. Die vollständige Migration, einschließlich des Imports, dauert ggf. mehrere Stunden. Daher wird empfohlen, einen Probelauf durchzuführen, um die Länge des vollständigen Prozesses ermitteln zu können. Weitere Informationen finden Sie unter Informationen zu „ghe-migrator“.

  2. Starte eine Migration, indem du eine POST-Anforderung an den Migrationsendpunkt sendest. Sie benötigen Folgendes:

    • Dein Zugriffstoken für die Authentifizierung.

    • Eine Liste der Repositorys, die du migrieren möchtest:

      curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
      -X POST \
      -H "Accept: application/vnd.github+json" \
      -d'{"lock_repositories":true,"repositories":["ORG_NAME/REPO_NAME", "ORG_NAME/REPO_NAME"]}' \
      https://api.github.com/orgs/ORG_NAME/migrations
      
    • Wenn du die Repositorys vor der Migration sperren möchtest, stelle sicher, dass lock_repositories auf true festgelegt ist. Dies wird dringend empfohlen.

    • Du kannst Dateianlagen ausschließen, indem du exclude_attachments: true an den Endpunkt übergibst. Dateianhänge können groß sein und blähen Ihr endgültiges Migrationsarchiv ggf. unnötig auf. Die endgültige Archivgröße muss kleiner als 20 GB sein.

    Diese Anforderung gibt einen eindeutigen id-Wert zurück, der deine Migration darstellt. du benötigst diese für nachfolgende Aufrufe der API für Migrationen.

  3. Sende eine GET-Anforderung an den Migrationsstatusendpunkt, um den Status einer Migration abzurufen. Sie benötigen Folgendes:

    • Dein Zugriffstoken für die Authentifizierung.

    • Die eindeutige id der Migration:

      curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
      -H "Accept: application/vnd.github+json" \
      https://api.github.com/orgs/ORG_NAME/migrations/ID
      

    Eine Migration kann einen der folgenden Zustände aufweisen:

    • pending, was bedeutet, dass die Migration noch nicht gestartet wurde.
    • exporting, was bedeutet, dass die Migration ausgeführt wird.
    • exported, was bedeutet, dass die Migration erfolgreich abgeschlossen wurde.
    • failed, was bedeutet, dass bei der Migration ein Fehler aufgetreten ist.
  4. Lade nach dem Export deiner Migration das Migrationsarchiv herunter, indem du eine GET-Anforderung an den Migrationsdownload-Endpunkt sendest. Sie benötigen Folgendes:

    • Dein Zugriffstoken für die Authentifizierung.

    • Die eindeutige id der Migration:

      curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
      -H "Accept: application/vnd.github+json" \
      -L -o migration_archive.tar.gz \
      https://api.github.com/orgs/ORG_NAME/migrations/ID/archive
      
  5. Das Migrationsarchiv wird nach sieben Tagen automatisch gelöscht. Wenn du es früher löschen möchtest, kannst du eine DELETE-Anforderung an den Löschendpunkt des Migrationsarchivs senden. Sie benötigen Folgendes:

    • Dein Zugriffstoken für die Authentifizierung.

    • Die eindeutige id der Migration:

      curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
      -X DELETE \
      -H "Accept: application/vnd.github+json" \
      https://api.github.com/orgs/ORG_NAME/migrations/ID/archive
      
  6. Informationen zum Vorbereiten der archivierten Migrationsdaten für den Import in eine GitHub Enterprise Server-Instanz findest du unter Migrieren von Daten zu GitHub Enterprise Server.