Übersicht über die Migration zwischen GitHub-Produkten

Übersicht

Mit GitHub Enterprise Importer können Sie zu GitHub Enterprise Cloud migrieren. Weitere Informationen finden Sie unter Informationen zu GitHub Enterprise Importer.

Wenn Sie zwischen GitHub Produkten migrieren, z. B. von GitHub Enterprise Server zu GitHub Enterprise Cloud, können Sie diesen Leitfaden verwenden, um Ihre Migration zu planen und zu implementieren und Nachverfolgungsaufgaben 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öchten wir entweder pro Organisation oder pro Repository migrieren?

Zunächst sollten Sie, wenn Ihre Migrationsquelle GitHub.com ist, entscheiden, ob Sie pro Organisation oder pro Repository migrieren möchten.

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?

Stellen Sie sicher, dass Sie und Ihre Stakeholder verstehen, welche Daten durch 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 den GitHub-Produkten mit 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. Sie können die Migrator-Rolle für Unternehmenskonten nicht 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 finden Sie 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 finden Sie unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.

   Hinweis

   Vergessen Sie nicht, die Migrator-Rolle 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 finden Sie 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, insbesondere wenn Sie von GitHub.com migrieren, da Sie mit einem einzigen Befehl eine gesamte Organisation migrieren können. Wenn Sie von einer anderen Quelle migrieren, kann GitHub CLI ein Skript generieren, um alle Repositories für eine einzelne 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. Verwenden Sie den GitHub CLI Befehl, und verschieben Sie 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.

Was ist unser Plan für Unternehmens- und Organisationsnamen?

Wenn Sie zwischen Konten GitHub.commigrieren, denken Sie daran, dass es Benennungseinschränkungen für Benutzer-, Organisations- und Unternehmenskonten gibt. 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 auf GitHub Enterprise teilen sich denselben Namespace; zwei Benutzer- oder Organisationskonten können nicht denselben Namen haben. Unternehmenskonten auf GitHub Enterprise teilen sich denselben Namespace; zwei Unternehmenskonten können 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 Ihre Quellorganisation IP-Zulassungslisten verwendet, konfigurieren Sie die Liste so, dass GitHub Enterprise Importer Zugriff erhält. 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 finden Sie unter Verwalten des Zugriffs für eine Migration zwischen GitHub-Produkten.

8. Wenn Sie eine Migration eines Repositorys durchführen und Einstellungen für GitHub Advanced Security Produkte migrieren möchten, aktivieren Sie 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.

Abschließen 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 GitHub Actions
• Konfigurieren von IP-Zulassungslisten
• Verwalten von GitHub Advanced Security Funktionen
• Aktivieren von Webhooks
• Neuinstallation GitHub Apps
• Neuorganisation von Teams
• Wiederaufarbeiten 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 Quell-Repository Git LFS verwendet, können Sie Git LFS-Objekte manuell lokal in das migrierte Repository 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 können Sie GitHub CLI verwenden, um die Sichtbarkeit des Repositorys über die Befehlszeile zu ändern. Weitere Informationen finden Sie gh repo edit in der GitHub CLI Dokumentation.

GitHub Actions konfigurieren

Wenn Sie in einem Repository verwenden GitHub Actions , werden Ihre Workflows automatisch als Teil des Git-Repositorys migriert.

Während des Migrationsprozesses wird GitHub Actions für alle migrierten Repositories deaktiviert, um zu vermeiden, dass Workflows versehentlich ausgelöst werden, aber GitHub Actions wird wieder aktiviert, wenn die Migration abgeschlossen ist.

Wenn Sie größerer Runners, selbstgehostete Runner oder verschlüsselte Secrets verwendet haben, müssen Sie sie 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 erneut.

   • 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 Runners 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 GitHub CLIfinden Sie 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 Sie die IP-Bereiche für GitHub Enterprise Importer zu den IP-Zulassungslisten Ihrer Quell- oder Zielorganisationen hinzugefügt haben, können Sie 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.

Verwaltung von GitHub Advanced Security Features

Wenn Sie vor der Migration von Repositorys GitHub Advanced Security Produkte für die Zielorganisation aktiviert haben, wurden die Einstellungen für einzelne Funktionen 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 diesen aktualisierten Korrekturen zugeordnet ist, ist der Benutzer, der das personal access token für die API-Aufrufe verwendet hat, nicht der Benutzer, der die Warnung im Quell-Repository korrigiert hat, und das Datum, das der Wartung zugeordnet ist, ist das Datum des API-Aufrufs, nicht das Datum, an dem die Warnung im Quell-Repository behoben wurde.

Code scanning

Code scanning Warnungen werden nicht durch 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 Quell-Repository.

• Die Warnmeldungen umfassen nur die Erfassung und den aktuellen Status der Warnmeldung, nicht die gesamte Zeitleiste 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, wie z. B. der Ersteller der Warnung, werden in den Besitzer von personal access token, der für den API-Aufruf verwendet wird, geändert.

Dependabot alerts

Wenn Dependabot alerts und das Abhängigkeitsdiagramm aktiviert sind, wird Dependabot alerts aus dem aktuellen Status des Standard-Branchs neu erstellt. Der Behebungsstatus dieser Warnungen wird nicht migriert, ebenso wenig wie alle vorherigen Warnungen.

Sie müssen alle verschlüsselten Geheimnisse für Dependabot erneut hinzufügen. Weitere Informationen finden Sie unter Konfigurieren des Zugriffs auf private Registrierungen für Dependabot.

Funktionen für Datenresidenz neu konfigurieren

Wenn Sie von GitHub.com zu GitHub Enterprise-Cloud mit Datenresidenz" migriert" sind, funktionieren einige Features unterschiedlich, und einige Features erfordern eine andere oder zusätzliche Konfiguration. Weitere Informationen findest du unter Featureübersicht für GitHub Enterprise Cloud mit Data Residency.

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.

Die Neuinstallation GitHub Apps

Falls Sie GitHub Apps im Quell-Repository installiert hatten, müssen Sie diese im migrierten Repository erneut installieren. Weitere Informationen finden Sie unter Installieren Ihrer eigenen GitHub App.

Teams neu erstellen

Wenn du die Migration für jede Organisation einzeln durchgeführt hast, musst du nur die Teammitgliedschaft reaktivieren. Wenn Sie für jedes einzelne Repository die Migration durchgeführt haben, müssen Sie Teams neu erstellen, diesen Teams Zugriff auf die Repositorys gewähren und dann die Teammitgliedschaft wiederherstellen.

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 finden Sie unter Konfigurieren der SCIM-Bereitstellung zum Verwalten von Benutzern oder für Unternehmen, die nicht verwenden Enterprise Managed Users, Verwalten der Teamsynchronisierung für Organisationen in deinem Unternehmen.

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 im Rahmen einer Repository-Migration nicht 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.

Zurückgewinnen von Mannequins

Nachdem Sie eine Migration mit GitHub Enterprise Importer oder Enterprise Live Migrations ausgeführt haben, 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.