Übersicht über die Migration zwischen GitHub-Produkten

Übersicht

Mit GitHub Enterprise Importer kannst du zu GitHub Enterprise Cloud migrieren. Weitere Informationen finden Sie unter Informationen zu 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 Informationen zu 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?
• Wie schnell muss die Migration abgeschlossen werden?
• Weißt du, was migriert wird?
• Wer führt die Migration aus?
• Möchtest du nach der Migration eine ähnliche Organisationsstruktur beibehalten?

Möchtest du nach Organisation oder nach Repository migrieren?

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

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. Um diese Daten zu sammeln, verwende die gh-repo-stats Erweiterung fürGitHub CLI. 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. Verwende die gh-repo-stats Erweiterung fürGitHub CLI und überprüfe dann einen 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 finden Sie unter Informationen zu Migrationen zwischen GitHub-Produkten.
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 finden Sie unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.
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 eine Migration zwischen GitHub-Produkten.

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 Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.

   Hinweis

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

4. 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 eine Migration zwischen GitHub-Produkten.

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.

1. Entscheide, wie deine neue Organisationsstruktur aussehen soll.
2. Entscheide, ob du den Migrationsaufwand in kleinere Batches aufteilen musst.
3. Bei einer Aufteilung musst du außerdem entscheiden, wie du die Migrationsvorgänge aufteilen möchtest.

Hinweise zu Unternehmens- und Organisationsnamen

Bei Migrationen zwischen Konten auf GitHub.com solltest du die Benennungseinschränkungen für Benutzer-, Organisations- und Enterprise-Konten bedenken. Wenn du einen Organisations- oder Unternehmensnamen für die Migration erneut verwenden musst, wird empfohlen, Konten vorher umzubenennen, anstatt sie zu löschen. Durch die Umbenennung ist der Name des Benutzer-, Organisations- oder Enterprise-Kontos sofort für die erneute Verwendung verfügbar.

Organisationskonten in GitHub Enterprise teilen denselben Namespace. Daher dürfen zwei Benutzer- oder Organisationskonten nicht denselben Namen haben. Enterprise-Konten in GitHub Enterprise teilen denselben Namespace. Daher dürfen zwei Enterprise-Konten nicht denselben Namen haben.

Ausführen deiner Migrationen

Um Probleme aufzudecken, die für Ihr Unternehmen möglicherweise einzigartig sind, empfehlen wir dringend, eine Testausführung Ihrer Migration durchzuführen. Bei einer Testversion lernen Sie Folgendes:

• Gibt an, ob die Migration für ein bestimmtes Repository erfolgreich abgeschlossen werden kann.
• Gibt an, ob Sie das migrierte Repository wieder in einen funktionsfähigen Zustand zurückholen können.
• Wie lange eine Migration dauern wird.

Testläufe können jederzeit ausgeführt werden, und die Arbeit muss während der Migration nicht angehalten werden. 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. Benutzer*innen 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 finden Sie unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.
3. Führe die Testmigrationsvorgänge aus.
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.
7. Wenn am Ziel 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 eine Migration zwischen GitHub-Produkten.
8. Wenn du eine Repositorymigration durchführst und du die Einstellungen für GitHub Advanced Security products migrieren möchtest, aktiviere GitHub Advanced Security-Produkte für die Zielorganisation. Weitere Informationen finden Sie unter Verwalten von Sicherheits- und Analyseeinstellungen für deine Organisation.
9. Führe deine Produktionsmigrationen aus. Weitere Informationen findest du unter Informationen zu GitHub Enterprise Importer oder Migrieren von Repositorys von GitHub.com zu GitHub Enterprise Cloud.
10. Lösche optional die Testorganisation.

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 Migrationsstatus
• Überprüfen des Migrationsprotokolls
• Migrieren von Git LFS-Objekten
• Sichtbarkeit eines Repositorys festlegen
• Konfigurieren von GitHub Actions
• Konfigurieren von IP-Zulassungslisten
• Verwalten von GitHub Advanced Security-Features
• Aktivieren von Webhooks
• Erneutes Installieren von GitHub Apps
• Erneutes Erstellen von Teams
• Freigeben von Mannequins

Überprüfen des Migrationsstatus

Überprüfen Sie zunächst, ob die Migration erfolgreich war oder fehlgeschlagen ist.

Die Art und Weise, wie Sie den Status Ihrer Migration überprüfen, hängt davon ab, wie Sie die Migration ausgeführt haben.

• Wenn Sie die Migration mit GitHub CLI ausgeführt haben, zeigt der Prozess standardmäßig an, ob die Migration erfolgreich war oder fehlgeschlagen ist, sobald die Migration abgeschlossen ist. Wenn die Migration fehlgeschlagen ist, wird der Grund für einen Fehler angezeigt.

  Migration completed (ID: RM_123)! State: SUCCEEDED
  

• Wenn Sie die Migration mit GitHub CLI mit dem optionalen --queue-only-Argument ausgeführt haben, wird der Prozess unmittelbar nach dem Einstellen in die Warteschlange der Migration beendet und teilt Ihnen nicht mit, ob die Migration erfolgreich war oder fehlgeschlagen ist. Sie können den Status einer Migration mithilfe des wait-for-migration-Befehls überprüfen oder das Migrationsprotokoll überprüfen.

• Wenn Sie die Migration mit der GraphQL-API ausgeführt haben, können Sie die Felder state und failureReason des RepositoryMigration-Objekts abfragen.

Wenn die Migration fehlgeschlagen ist, enthält das Migrationsprotokoll möglicherweise zusätzliche Informationen zur Ursache des Fehlers. Weitere Informationen findest du unter Prüfen des Migrationsprotokolls.

Überprüfen des Migrationsprotokolls

Überprüfen Sie das Migrationsprotokoll für jedes migrierte Repository. Weitere Informationen finden Sie unter Zugriff auf die Migrationsprotokolle von GitHub Enterprise Importer.

Wenn die Migration fehlgeschlagen ist, enthält das Protokoll möglicherweise zusätzliche Informationen zur Ursache des Fehlers.

Wenn die Migration erfolgreich war, gibt es möglicherweise Warnungen im Migrationsprotokoll, die bestimmte Datenelemente darstellen (z. B. Pull Requests, Probleme oder Kommentare), die nicht migriert oder mit Vorbehalten migriert wurden.

Weitere Informationen zum Verständnis von Migrationswarnungen findest du unter Problemlösung bei der Migration mit GitHub Enterprise Importer. Nach der Überprüfung von Migrationswarnungen müssen Sie entscheiden, ob Sie diese Warnungen akzeptieren und weitergehen können.

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 finden Sie unter Ein Repository duplizieren.

Sichtbarkeit eines Repositorys festlegen

Alle Repositorys werden standardmäßig als privat migriert, und nur die Person, die die Migration ausgeführt hat, sowie die Organisationsbesitzer*innen 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 finden Sie unter Sichtbarkeit eines Repositorys festlegen.
• Alternativ kannst du mit GitHub CLI die Sichtbarkeit des Repositorys über die Befehlszeile ändern. 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 Sie größerer Runners, selbst gehostete Runner oder verschlüsselte Geheimnisse verwendet haben, müssen Sie diese neu konfigurieren.

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

   • Füge dem entsprechenden Repository, der Organisation oder dem entsprechenden Unternehmen Runner hinzu. Weitere Informationen finden Sie unter Selbst-gehostete Runner hinzufügen.
   • Um Runner auf Organisations- oder Unternehmensebene zu verwenden, aktualisiere deine Workflows. Weitere Informationen finden Sie unter Verwenden von selbstgehosteten Runnern in einem Workflow.

2. Wenn Sie größerer Runners verwenden, konfigurieren Sie Ihre Runner neu.

   • Konfigurieren Sie Runnergruppen, um den Zugriff auf Ihre Runner zu steuern. Weitere Informationen finden Sie unter Steuern des Zugriffs auf größere Runner.
   • Richten Sie Ihre größerer Runner ein. Weitere Informationen finden Sie unter Verwalten größerer Runner.
   • Aktualisieren Sie Ihre Workflows so, dass sie auf Ihre Runner zeigen. Weitere Informationen finden Sie unter Ausführen von Aufträgen auf größeren Runnern.

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

   • Informationen zur Verwendung des Browsers findest du unter Verwenden von Geheimnissen in GitHub-Aktionen.
   • Informationen zur Verwendung der GitHub CLI findest du unter gh secret in der GitHub CLI-Dokumentation.

4. Konfiguriere Umgebungen neu. Weitere Informationen finden Sie unter Verwalten 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 finden Sie unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.

Verwalten von GitHub Advanced Security-Features

Wenn du GitHub Advanced Security-Produkte für die Zielorganisation vor der Migration der Repositorys aktiviert hast, wurden die Einstellungen für die einzelnen Features migriert. Andernfalls musst du einzelne Features nach der Migration erneut aktivieren. Weitere Informationen finden Sie 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 finden Sie unter REST-API-Endpunkte für das Secret Scanning.

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 finden Sie unter REST-API-Endpunkte für die 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 finden Sie unter Konfigurieren des Zugriffs auf private Registrierungen für Dependabot.

Neukonfiguration von Features für Datenresidenz

Nach einer Migration von GitHub.com zu GitHub Enterprise-Cloud mit Datenresidenz funktionieren einige Features anders und für einige Features sind andere oder weitere Konfigurationsschritte erforderlich. Weitere Informationen findest du unter Übersicht der Funktionen für GitHub Enterprise Cloud mit Datenresidenz.

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 finden Sie unter Installieren Ihrer eigenen 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 zum Verwalten von Benutzern. 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 finden Sie 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 finden Sie unter Erstellen eines Organisationsteams.
2. Füge Organisationsmitglieder zu Teams hinzu. Weitere Informationen finden Sie unter Organisationsmitglieder zu einem Team hinzufügen.
3. Gewähre jedem Team Zugriff auf das Repository. Weitere Informationen finden Sie 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.

1. Entscheide, ob du Mannequins zurückholen möchtest.
2. Plane, wann du die Rückforderungen abschließen wirst.
3. Gib die Mannequins frei. Sie können den Verlauf für jedes Mannequin zu einem Organisationsmitglied mit der GitHub CLI oder in Ihrem Browser neu attributen. Wenn Sie die GitHub CLI verwenden, können Sie Mannequins massenweise zurückfordern. Weitere Informationen findest du unter Freigeben von Mannequins für GitHub Enterprise Importer.
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 finden Sie unter Den Zugriff einer Person auf ein Repository einer Organisation verwalten.