Skip to main content
Wir veröffentlichen regelmäßig Aktualisierungen unserer Dokumentation, und die Übersetzung dieser Seite ist möglicherweise noch nicht abgeschlossen. Aktuelle Informationen findest du in der englischsprachigen Dokumentation.
All products
Migrationen

Migrieren zwischen GitHub-Produkten mit GitHub Enterprise Importer

In diesem Artikel

Hier erfährst du, wie du den gesamten Prozess der Migration von einem GitHub-Produkt zu einem anderen von der Planung über die Implementierung bis hin zum Abschluss von Folgeaufgaben durchführst.

Hinweis: Der GitHub Enterprise Importer liegt derzeit als öffentliche Betaversion vor und kann noch geändert werden.

Informationen zu Migrationen zwischen GitHub-Produkten

Mit GitHub Enterprise Importer kannst du zu GitHub Enterprise Cloud migrieren. Weitere Informationen findest du unter About GitHub Enterprise Importer.

Wenn du zwischen GitHub-Produkten migrierst, z. B. von GitHub Enterprise Server zu GitHub Enterprise Cloud, kannst du diesen Leitfaden verwenden, um deine Migration zu planen und zu implementieren und Folgeaufgaben abzuschließen. Eine vollständige Liste der unterstützten Migrationspfade findest du unter Migrationsunterstützung für GitHub Enterprise Importer.

Planen der Migration

Stelle dir die folgenden Fragen, um deine Migration zu planen.

Möchtest du nach Organisation oder nach Repository migrieren?

Wenn deine Migrationsquelle und dein Ziel GitHub.com sind, entscheide zunächst, ob du auf Basis der einzelnen Organisationen oder auf Basis der einzelnen Repositorys migrieren möchtest.

Hinweis: Wenn du von GitHub Enterprise Server migrierst, kannst du nur Repositorys migrieren.

Wenn du eine Migration auf Basis einzelner Repositorys durchführst, werden nur Daten auf Repositoryebene migriert. Wenn du die Migrationsstrategie auf Organisationsbasis durchführst, werden auch ausgewählte Daten auf Organisationsebene migriert, einschließlich Teams und deren Zugriff auf Repositorys.

Wenn du jedoch eine Organisation migrierst, werden alle Repositorys, die der Quellorganisation gehören, gleichzeitig migriert. Du kannst die Repositorys nicht in Batches aufteilen oder die Migration von Repositorys der Organisation auslassen. Wenn du über eine große Anzahl von Repositorys verfügst oder wenn du keine Downtime für alle deine Repositories zur gleichen Zeit tolerieren kannst, solltest du stattdessen Repositorymigrationen ausführen.

Darüber hinaus wird bei einer Organisationsmigration eine neue Organisation im Zielunternehmenskonto erstellt. Wenn du Repositorys zu einer vorhandenen Organisation migrieren möchtest, musst du stattdessen Repositorymigrationen ausführen.

Schließlich musst du Unternehmensbesitzer des Zielunternehmenskontos sein, um Organisationen zu migrieren. Wenn du eine Person, die kein Unternehmensbesitzer ist, mit der Durchführung deiner Migrationen beauftragen willst, muss sie Repositorymigrationen durchführen.

Wie schnell muss die Migration abgeschlossen werden?

Bestimme den Zeitplan für deinen Ansatz. Als ersten Schritt zum Bestimmen deines Zeitplans machst du eine Bestandsaufnahme der zu migrierenden Elemente. Verwende zum Sammeln dieser Daten das GitHub-Migrationsanalysetool. Dieses Open-Source-Tool generiert einen Bericht, in dem beschrieben wird, wie viele Daten für eine Organisation migriert werden müssen.

  • Anzahl von Repositorys
  • Anzahl der Pull Requests
  • Anzahl der Probleme
  • Anzahl an Benutzern
  • Nutzung von Projekten und Wikis

Der Zeitplan für die Migration hängt weitgehend von der Anzahl der Pull Requests und Issues in einem Repository ab. Wenn du 1.000 Repositorys migrieren möchtest und jedes Repository durchschnittlich 100 Pull Requests und Issues aufweist und nur 50 Benutzer zu den Repositorys beigetragen haben, wird ihre Migration wahrscheinlich sehr schnell erfolgen. Wenn du nur 100 Repositorys migrieren möchtest, aber die Repositorys durchschnittlich 75.000 Pull Requests und Issues und 5.000 Benutzer aufweisen, dauert die Migration länger und erfordert viel mehr Planung und Tests.

Nachdem du das Analysetool verwendet hast, kannst du deine Bestandsdaten mit der gewünschten Zeitskala auswerten. Wenn deine Organisation eine größere Anzahl von Änderungen verträgt, kannst du möglicherweise auch alle deine Repositorys gleichzeitig migrieren und so deine Migration in wenigen Tagen abschließen. Möglicherweise können jedoch nicht alle Teams gleichzeitig migriert werden. In diesem Fall solltest du die Migration in Batches und gestaffelt nach den Planungen der Teams anpassen und so deine Migration schrittweise ausdehnen.

  1. Verwenden das GitHub-Migrationsanalysetool, und überprüfe dann deinen Migrationsbestand.
  2. Um zu verstehen, wann die einzelne Teams für die Migration bereit sein können, solltest du mit allen Projektbeteiligten reden.
  3. Sieh dir den Rest dieses Leitfadens an, und entscheide dich dann für einen Zeitplan für die Migration.

Weißt du, was migriert wird?

Stelle sicher, dass du und deine Projektbeteiligten verstehen, welche Daten von GitHub Enterprise Importer migriert werden können.

  1. Überprüfe die Daten, die für deine Migrationsquelle migriert werden. Weitere Informationen findest du unter Migrationsunterstützung für GitHub Enterprise Importer.
  2. Erstelle eine Liste aller Daten, die du manuell migrieren oder neu erstellen musst.

Wer führt die Migration aus?

Entscheide, wer die Migration ausführen soll, und stelle sicher, dass diese Person über den erforderlichen Zugriff verfügt. Deine Optionen hängen davon ab, ob du nach Organisation oder nach Repository migrierst.

Wer führt die Organisationsmigrationen durch?

Um eine Organisation zu migrieren, musst du Organisationsbesitzer der Quellorganisation sein, oder ein Organisationsbesitzer muss dir die Migrationsrolle für diese Organisation gewähren.

Darüber hinaus musst du Unternehmensbesitzer für das Zielunternehmenskonto sein. Du kannst die Migrationsrolle nicht für Unternehmenskonten gewähren.

  1. Vergewissere dich, dass die Person, die deine Migrationen ausführt, ein Unternehmensbesitzer des Zielunternehmenskontos ist.
  2. Wenn diese Person kein Organisationsbesitzer der Quellorganisation ist, gewähre ihr die Migrationsrolle für die Organisation. Weitere Informationen findest du unter Zuweisen der Migrationsrolle zu GitHub Enterprise Importer.
  3. Vergewissere dich, dass die Person die personal access token ordnungsgemäß konfiguriert hat, sodass sie alle Zugriffsanforderungen erfüllen. Weitere Informationen findest du unter Verwalten des Zugriffs für GitHub Enterprise Importer.

Wer führt die Repositorymigrationen durch?

Um ein Repository zu migrieren, musst du der Organisationsbesitzer der Quellorganisation sowie der Zielorganisation sein, oder ein Organisationsbesitzer muss dir die Migrationsrolle für jede Organisation gewähren, deren Besitzer du nicht bist.

  1. Entscheide, ob ein Organisationsbesitzer deine Migrationen durchführen soll oder ob du die Migrationsrolle einer anderen Person erteilen musst.

  2. Wenn du dich für die Rolle „Migrator“ entschieden hast, musst du entscheiden, welcher Person oder welchem Team du die Rolle zuweisen möchtest.

  3. Weise der Person oder dem Team die Rolle „Migrator“ zu. Weitere Informationen findest du unter Zuweisen der Migrationsrolle zu GitHub Enterprise Importer.

    Hinweis: Denke daran, die Migrationsrolle sowohl für die Quellorganisation als auch für die Zielorganisation zu gewähren.

    1. Vergewissere dich, dass die Person die personal access token ordnungsgemäß konfiguriert hat, sodass sie alle Zugriffsanforderungen erfüllen. Weitere Informationen findest du unter [AUTOTITLE](/migrations/using-github-enterprise-importer/preparing-to-migrate-with-github-enterprise-importer/managing-access-for-github-enterprise-importer).

Möchtest du nach der Migration eine ähnliche Organisationsstruktur beibehalten?

Überlege als Nächstes, ob du nach der Migration eine ähnliche Organisationsstruktur beibehalten möchtest. Wenn du deine Migration in Batches aufteilen möchtest, kannst du hiermit deine Batches ermitteln. Wenn du eine eindeutige Entsprechung zwischen Organisationen in deiner Quelle und deinem Ziel haben möchtest, dann solltest du die Migrationen nach Organisationen in Batches durchführen. Dies ist der einfachste Ansatz, vor allem wenn du von GitHub.com migrierst, weil du eine ganze Organisation mit einem Befehl migrieren kannst. Wenn du von einer anderen Quelle migrierst, kann die GitHub CLI ein Skript generieren, um alle Repositorys in einer einzelnen Organisation zu migrieren.

Wenn du deine Organisationsstruktur ändern möchtest, solltest du weitere Batchingfaktoren berücksichtigen. Du kannst Repositorys in Batches aufteilen, die ähnlichen Teams oder einem Geschäftsbereich gehören, oder du kannst sie nach der Zielorganisation in Batches aufteilen. Es wird empfohlen, nach Möglichkeit eine Batchverarbeitung nach Teams durchzuführen. Wenn du Batches nach Geschäftsbereich oder Zielorganisationen aufteilst, erhöhst du die Anzahl der Projektbeteiligten, was zu kürzeren Zeitfenstern für deine Migrationen führen kann.

Auch wenn du deine Organisationsstruktur änderst, kannst du dennoch ein Skript für deine Migration vorbereiten. Verwende den Befehl GitHub CLI, und verschiebe dann die Zeilen für jedes Repository nach Bedarf in verschiedene Skripts.

Hinweis: Du kannst mehrere Batches gleichzeitig ausführen. Wenn du Batches beispielsweise nach Teams aufteilst, kannst du die Migrationen für mehrere Teams im selben Zeitfenster ausführen.

  1. Decide what your new organization structural will be.
  2. Decide if you need to break up your migration effort into smaller batches.
  3. If so, decide how you want to break up your migrations.

Ausführen deiner Migrationen

Nachdem du deine Planung abgeschlossen hast, kannst du die eigentlichen Migrationsvorgänge starten. Um Probleme während oder nach der Migration aufzudecken, die möglicherweise für dein Unternehmen einzigartig sind, wird dringend empfohlen, Testläufe aller Migrationsvorgänge durchzuführen. Nachdem du alle Probleme behoben hast, die bei den Testläufen entdeckt wurden, kannst du die Produktionsmigration ausführen.

Testmigrationsläufe helfen dabei, wichtige Informationen zu sammeln.

  • Kann die Migration für ein bestimmtes Repository erfolgreich abgeschlossen werden?
  • Kann das Repository wieder in einen Zustand versetzt werden, in dem die Benutzer*innen erfolgreich mit der Arbeit beginnen können?
  • Wie lange dauert die Ausführung einer Migration? Dies ist nützlich für die Planung von Migrationszeitplänen und das Festlegen der Erwartungen der Beteiligten.

Testläufe erfordern nicht viel Zeit für die Planung. GitHub Enterprise Importer verursacht nie Ausfallzeiten für Benutzerinnen eines zu migrierenden Repositorys. Es wird jedoch empfohlen, die Arbeit während der Produktionsmigration zu unterbrechen, um sicherzustellen, dass während der Migration keine neuen Daten erstellt werden, die dann im migrierten Repository fehlen würden. Dies stellt bei einer Testmigration kein Problem dar, sodass Testläufe jederzeit stattfinden können. Um die Zeit zu verkürzen, die zum Abschließen deiner Testmigration benötigt wird, kannst du die Batches für die Testläufe so planen, dass sie nacheinander ausgeführt werden. Benutzerinnen dieser Repositorys können die Ergebnisse dann selbst überprüfen.

Für Repositorymigrationen wird empfohlen, eine Testorganisation zu erstellen, die als Ziel für deine Testmigrationen verwendet wird. Du kannst eine einzelne Organisation für alle Testläufe verwenden, oder du kannst eine Testorganisation für jede vorgesehene Zielorganisation erstellen. Erwäge, am Ende der Organisationsnamen -sandbox einzufügen, um zu verdeutlichen, dass die Organisationen nur für die Migrationsvalidierung und nicht für die Produktion vorgesehen sind. Du kannst die Testorganisationen löschen, wenn du fertig bist.

  1. Wenn du eine Repositorymigration durchführst, erstelle eine Testorganisation für deine Testmigrationen.
  2. Wenn in der Quellorganisation Listen zulässiger IP-Adressen verwendet werden, musst du die Liste so konfigurieren, dass der Zugriff von GitHub Enterprise Importer zugelassen wird. Weitere Informationen findest du unter Verwalten des Zugriffs für GitHub Enterprise Importer.
  3. Führe die Testmigrationsvorgänge aus. Weitere Informationen findest du unter Vorbereiten einer Migration mit GitHub Enterprise Importer.
  4. Führe die unten beschriebenen Nachverfolgungsaufgaben für die Testmigrationsvorgänge aus.
  5. Bitte die Benutzer*innen, die Ergebnisse der Migrationsvorgänge zu überprüfen.
  6. Behebe alle Probleme, die durch die Testmigrationsvorgänge aufgedeckt wurden. 1. If your destination uses IP allow lists, configure the list to allow access by GitHub Enterprise Importer. For more information, see "Verwalten des Zugriffs für GitHub Enterprise Importer."
  7. Wenn du eine Repositorymigration durchführen und GitHub Advanced Security-Einstellungen migrieren möchtest, aktiviere GitHub Advanced Security für die Zielorganisation. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation.
  8. Führe deine Produktionsmigrationen aus. Weitere Informationen findest du unter Migrieren von Repositorys mit GitHub Enterprise Importer oder Migrieren von Organisationen mit GitHub Enterprise Importer.
  9. Optionally, delete the test organization.

Ausführen von Folgeaufgaben

Nachdem alle Migrationsvorgänge abgeschlossen wurden, musst du einige zusätzliche Aufgaben ausführen, bevor das Repository einsatzbereit ist.

Überprüfen des Migrationsprotokolls

Überprüfe zunächst das Migrationsprotokoll für jedes migrierte Repository. Weitere Informationen findest du unter Zugreifen auf die Migrationsprotokolle für GitHub Enterprise Importer.

Wenn bestimmte Elemente im Repository nicht migriert werden konnten, wird im Migrationsprotokoll eine Warnung angezeigt.

Hinweis: Wenn das Issue „Migrationsprotokoll“ unten „Migration abgeschlossen“ enthält, wurde das Repository migriert. Fehlermeldungen weisen nur darauf hin, dass bestimmte Elemente innerhalb des Repositorys, z. B. ein Kommentar zu einem Pull Request, möglicherweise nicht ordnungsgemäß migriert wurden.

  1. Überprüfe deine Migrationsprotokolle.
  2. Überprüfe alle Warnungen in jedem Protokoll, und stelle sicher, dass keine die Übernahme der Migration blockiert. Weitere Informationen findest du unter Behandeln von Problemen bei der Migration mit GitHub Enterprise Importer.

Migrieren von Git LFS-Objekten

GitHub Enterprise Importer migriert keine Git LFS-Objekte. Wenn das Quellrepository Git LFS verwendet, kannst du Git LFS-Objekte manuell in das migrierte Repository lokal pushen. Weitere Informationen findest du unter Ein Repository duplizieren.

Sichtbarkeit eines Repositorys festlegen

Alle Repositorys werden als privat migriert, und nur die Benutzerinnen, die die Migration ausgeführt haben, sowie die Organisationsbesitzerinnen haben Zugriff auf das Repository. Wenn du nicht möchtest, dass das Repository privat ist, musst du seine Sichtbarkeit ändern.

  • Du kannst die Sichtbarkeit eines Repositorys im Browser ändern. Weitere Informationen findest du unter Sichtbarkeit eines Repositorys festlegen.
  • Alternativ kannst du mit GitHub CLI die Sichtbarkeit des Repositorys über die Befehlszeile ändern. Du kannst diesen Befehl sogar dem Skript hinzufügen, das zum Ausführen deiner Migrationsvorgänge generiert wurde. Weitere Informationen findest Du gh repo edit in der Dokumentation zur GitHub CLI.

Konfigurieren von GitHub Actions

Wenn du GitHub Actions in einem Repository verwendest, werden deine Workflows automatisch als Teil des Git-Repositorys migriert.

Während des Migrationsprozesses ist GitHub Actions für alle migrierten Repositorys deaktiviert, um zu vermeiden, dass Workflows versehentlich ausgelöst werden, aber GitHub Actions wird nach Abschluss der Migration wieder aktiviert.

Wenn du selbstgehostete Runner oder verschlüsselte Geheimnisse verwendest, musst du sie neu konfigurieren.

Hinweis: Der Workflowausführungsverlauf für GitHub Actions ist nicht in Migrationen enthalten.

  1. Wenn du selbstgehostete Runner verwendest, konfiguriere deine Runner neu.

  2. Füge alle verschlüsselten Geheimnisse erneut hinzu.

    • Informationen zur Verwendung des Browsers findest du unter Verschlüsselte Geheimnisse.
    • Informationen zur Verwendung der GitHub CLI findest du unter gh secret in der GitHub CLI-Dokumentation.

  3. Konfiguriere Umgebungen neu. Weitere Informationen findest du unter Verwenden von Umgebungen für die Bereitstellung.

Konfigurieren von IP-Zulassungslisten

Wenn du die IP-Adressbereiche für GitHub Enterprise Importer den IP-Zulassungslisten für deine Quell- oder Zielorganisationen hinzugefügt hast, kannst du diese Einträge entfernen. Wenn du die Einschränkungen durch die Liste zulässiger IP-Adressen deines Identitätsanbieters für dein Zielunternehmen deaktiviert hast, kannst du sie jetzt erneut aktivieren.

Weitere Informationen findest du unter Verwalten des Zugriffs für GitHub Enterprise Importer.

Verwalten von GitHub Advanced Security

Wenn du GitHub Advanced Security für die Zielorganisation vor der Repositorymigration aktiviert hast, wurden die Einstellungen für einzelne Features migriert. Andernfalls musst du einzelne Features nach der Migration erneut aktivieren. Weitere Informationen findest du unter Verwalten von Sicherheits- und Analyseeinstellungen für dein Repository.

Für jedes Feature gibt es zusätzliche Arbeitsschritte nach der Migration.

Secret scanning

Wenn die Geheimnisüberprüfung für das Zielrepository aktiviert ist, wird eine Überprüfung des gesamten Repositorys durchgeführt. Nach Abschluss der Überprüfung werden alle Warnungen aufgefüllt, jedoch ohne Wartungsstatus.

Du kannst die REST-API verwenden, um die Warnungen zu aktualisieren, damit alle Wartungsmaßnahmen im Quellrepository reflektiert werden. Weitere Informationen findest du in der REST-API-Dokumentation unter Geheime Überprüfung.

Der Benutzer, der für diese aktualisierten Wartungsmaßnahmen zuständig ist, ist der Benutzer, dem das personal access token gehört, das für die API-Aufrufe verwendet wurde, und nicht der Benutzer, der die Warnung im Quellrepository behoben hat. Das Datum der Wartungsmaßnahme entspricht dem Datum des API-Aufrufs und nicht dem Zeitpunkt, an dem die Warnmeldung im Quellrepository behoben wurde.

Code scanning

Code scanning-Warnungen werden nicht von GitHub Enterprise Importer migriert. Die Warnungen sind jedoch als SARIF-Daten im Quellrepository verfügbar. Du kannst die REST-API verwenden, um diese Daten in das Zielrepository hochzuladen. Weitere Informationen findest du in der REST-API-Dokumentation unter Codeüberprüfung.

Code scanning-Warnungen, die auf diese Weise aufgefüllt werden, unterscheiden sich von den ursprünglichen Warnungen im Quellrepository.

  • Die Warnungen enthalten nur die Erkennung und den neuesten Status der Warnung, nicht die gesamte Zeitskala aus dem Quellrepository.
  • Die Warnungen werden nur als open oder fixed gekennzeichnet. Andere Wartungszustände, wie dismissed und reopened, gehen dabei verloren.
  • Die Datumsangaben aller Ereignisse in der Warnung entsprechen dem Datum des API-Aufrufs, nicht dem Zeitpunkt des ursprünglichen Auftretens der Ereignisse im Quellrepository.
  • Alle Akteure, beispielsweise der Ersteller der Warnung, wechseln zum Besitzer des personal access token, das für den API-Aufruf verwendet wird.

Dependabot alerts

Wenn Dependabot alerts und das Abhängigkeitsdiagramm aktiviert sind, wird Dependabot alerts aus dem aktuellen Zustand des Standardbranchs neu erstellt. Die Wartungsstatus dieser Warnungen werden nicht migriert, und alle vorherigen Warnungen werden ebenfalls nicht migriert.

Du musst alle verschlüsselten Geheimnisse für Dependabot erneut hinzufügen. Weitere Informationen findest du unter Konfigurieren des Zugriffs auf private Registrierungen für Dependabot.

Aktivieren von Webhooks

Alle aktiven Webhooks im Quellrepository werden migriert. Die migrierten Webhooks sind jedoch standardmäßig deaktiviert. Sie können diese Webhooks in den Repositoryeinstellungen erneut aktivieren.

  1. Navigieren Sie zu den Einstellungen für das migrierte Repository.
  2. Klicke auf der Seitenleiste im Abschnitt Code und Automatisierung auf Webhooks.
  3. Klicke rechts neben dem zu aktivierenden Webhook auf Bearbeiten.
  4. Wenn du zum Sichern des Webhooks ein geheimes Token verwendet hast, füge unter Geheimnis das Geheimnis erneut hinzu.
  5. Wähle am unteren Rand der Seite die Option Aktiv aus.
  6. Klicke auf Webhook aktualisieren.

Erneutes Installieren von GitHub Apps

Wenn du GitHub Apps im Quellrepository installiert hast, musst du sie im migrierten Repository neu installieren. Weitere Informationen findest du unter Installing your own GitHub App.

Erneutes Erstellen von Teams

Wenn du die Migration auf Organisationsbasis durchgeführt hast, musst du nur die Teammitgliedschaft reaktivieren. Wenn du die Migration auf Repositorybasis durchgeführt hast, musst du Teams neu erstellen, diesen Teams Zugriff auf Repositorys gewähren und dann die Teammitgliedschaft reaktivieren.

Erneutes Erstellen von Teams für Organisationsmigrationen

Teams und deren Repositoryzugriff werden im Rahmen einer Organisationsmigration migriert, die Teammitgliedschaft jedoch nicht. Nach der Migration musst du den migrierten Teams Benutzer hinzufügen.

Es wird dringend empfohlen, die Teamsynchronisierung zu verwenden, um die Teammitgliedschaft über deinen Identitätsanbieter (IdP) zu verwalten. Weitere Informationen findest du unter Konfigurieren der SCIM-Bereitstellung für Enterprise Managed Users. Unternehmen, die Enterprise Managed Users nicht verwenden, erhalten unter Verwalten der Teamsynchronisierung für Organisationen in deinem Unternehmen weitere Informationen.

Andernfalls kannst du deiner Organisation manuell Mitglieder hinzufügen und dann Organisationsmitglieder zu Teams hinzufügen. Weitere Informationen findest du unter Organisationsmitglieder zu einem Team hinzufügen.

Erneutes Erstellen von Teams für Repositorymigrationen

Teams werden nicht im Rahmen einer Repositorymigration migriert. Du musst Teams manuell neu erstellen und jedem Team Zugriff auf das Repository gewähren.

  1. Erstelle Teams neu. Weitere Informationen findest du unter Ein Team erstellen.
  2. Füge Organisationsmitglieder zu Teams hinzu. Weitere Informationen findest du unter Organisationsmitglieder zu einem Team hinzufügen.
  3. Gewähre jedem Team Zugriff auf das Repository. Weitere Informationen findest du unter Den Teamzugriff auf ein Repository einer Organisation verwalten.

Freigeben von Mannequins

Nachdem du eine Migration mit dem GitHub Enterprise Importer ausgeführt hast, werden alle Benutzeraktivitäten im migrierten Repository (mit Ausnahme von Git-Commits) Platzhalteridentitäten zugeordnet, die als Mannequins bezeichnet werden.

Du kannst den Verlauf für jedes Mannequin einem Organisationsmitglied neu zuordnen, indem du eine Zuordnungseinladung mit der GitHub CLI oder im Browser übermittelst. Wenn du die GitHub CLI verwendest, kannst du Mannequins in einem Massenvorgang freigeben. Weitere Informationen findest du unter Freigeben von Mannequins für GitHub Enterprise Importer.

Hinweis: Nur Organisationsbesitzerinnen können Mannequins freigeben. Wenn dir die Rolle „Migrator“ zugewiesen wurde, wende dich an die Organisationsbesitzerinnen, um diesen Schritt auszuführen.

  1. Entscheide, ob du Mannequins freigeben möchtest.
  2. Plane, wann du die Freigaben abschließen möchtest.
  3. Gib die Mannequins frei.
  4. Wenn eines der Mitglieder nicht bereits durch seine Teammitgliedschaft über den erforderlichen Zugriff auf das Repository verfügt, gewähre den Mitgliedern Zugriff auf das Repository. Weitere Informationen findest du unter Den Zugriff einer Person auf ein Repository einer Organisation verwalten.