Die Migrationstypen
Es gibt drei Migrationstypen, die von dir durchgeführt werden können:
- Eine Migration von einer GitHub Enterprise Server-Instanz zu einer anderen vorhandenen GitHub Enterprise Server-Instanz. Du kannst eine beliebige Anzahl an Repositorys migrieren, die einem Benutzer oder einer Organisation auf der Instanz gehören. Vor dem Durchführen einer Migration musst du über Websiteadministratorzugriff auf beide Instanzen verfügen.
- eine Migration von einer GitHub.com-Organisation zu einer GitHub Enterprise Server-Instanz. Du kannst eine beliebige Anzahl an Repositorys migrieren, die einer Organisation gehören. Vor dem Durchführen einer Migration musst du über Verwaltungszugriff auf die GitHub.com-Organisation und über Website-Administratorzugriff auf die Zielinstanz verfügen.
- Testausführungen sind Migrationen, die Daten in eine Staging-Instanz importieren. Mit diesen kann nachvollzogen werden, was passieren würde, wenn eine Migration auf deine GitHub Enterprise Server-Instanz angewendet würde. Es wird dringend empfohlen, dass du einen Probelauf auf einer Testinstanz durchführst, bevor du Daten in deine Produktionsinstanz importierst.
Hinweis: Die Verwendung von „ghe-migrator“ zum Übertragen einer GitHub Enterprise Server-Instanz zwischen Hypervisoren wird nicht empfohlen. Stattdessen wird empfohlen, die Instanz mit GitHub Enterprise Server Backup Utilities zu sichern und am neuen Speicherort wiederherzustellen, oder ein Replikats am neuen Speicherort zu erstellen und dann ein Failover zur Replikatappliance auszuführen. Weitere Informationen findest du unter Konfigurieren von Sicherungen auf deiner Appliance, Hochverfügbarkeitsreplikat erstellen und Initiieren eines Failovers zu deiner Replikat-Appliance.
Migrierte Daten
Bei „ghe-migrator“ dreht sich alles um ein Repository. Die meisten einem Repository zugeordneten Daten können migriert werden. Beispielsweise migriert ein Repository in einer Organisation das Repository und die Organisation sowie die dem Repository zugeordneten Benutzer, Teams, Issues und Pull Requests.
Die Elemente in der folgenden Tabelle können mit einem Repository migriert werden. Alle Elemente, die nicht in der Liste der migrierten Daten angezeigt werden, können nicht migriert werden, einschließlich Git LFS-Objekten.
Hinweis: Forkbeziehungen bleiben nach einer Migration nicht bestehen.
| Einem migrierten Repository zugeordnete Daten | Notizen |
|---|---|
| Benutzer | @mentions der Benutzer werden neu geschrieben, um dem Ziel zu entsprechen. |
| Organisationen | Der Name und die Details einer Organisation werden migriert. |
| Repositorys | Links zu Git-Strukturen, Blobs, Commits und Zeilen werden neu geschrieben, um dem Ziel zu entsprechen. Der Migrator folgt maximal drei Repository-Umleitungen. Interne Repositorys werden als private Repositorys migriert. Der Archivstatus wird gelöscht. |
| Wikis | Alle Wiki-Daten werden migriert. |
| Teams | @mentions der Benutzer werden neu geschrieben, um dem Ziel zu entsprechen. |
| Meilensteine | Zeitstempel werden beibehalten. |
| Projektboards | Projektboards, die dem Repository und der Organisation, welcher das Repository gehört, zugeordnet sind, werden migriert. |
| Probleme | Issue-Verweise und Zeitstempel werden beibehalten. |
| Issue-Kommentare | Querverweise auf Kommentare werden für die Zielinstanz neu geschrieben. |
| Pull Requests | Querverweise auf Pull Request werden neu geschrieben, um dem Ziel zu entsprechen. Zeitstempel werden beibehalten. |
| Pull-Request-Reviews | Pull-Request-Reviews und zugeordnete Daten werden migriert. |
| Pull-Request-Review-Kommentare | Querverweise auf Kommentare werden für die Zielinstanz neu geschrieben. Zeitstempel werden beibehalten. Kommentare auf Dateiebene werden nicht migriert. |
| Commit-Kommentare | Querverweise auf Kommentare werden für die Zielinstanz neu geschrieben. Zeitstempel werden beibehalten. |
| Releases | Die Daten sämtlicher Versionen werden migriert. |
| Bei Pull Requests oder Issues ergriffene Maßnahmen | Alle Änderungen an Pull Requests oder Issues, beispielsweise das Zuweisen von Benutzern, das Umbenennen von Titeln und das Ändern von Kennzeichnungen, werden zusammen mit den Zeitstempeln für die jeweilige Aktion beibehalten. |
| Dateianlagen | Dateianhänge für Issues und Pull Requests wurden migriert. Du kannst diese als Bestandteil der Migration deaktivieren. |
| webhooks | Nur aktive Webhooks werden migriert. |
| Repository-Deployment-Schlüssel | Repository-Deployment-Schlüssel werden migriert. |
| Geschützte Branches | Die Einstellungen für geschützte Branches und die zugeordneten Daten werden migriert. |