Die Migrationstypen
Es gibt drei Migrationstypen, die von Ihnen durchgeführt werden können:
- Eine Migration von einer GitHub Enterprise Server-Instanz zu einer anderen vorhandenen GitHub Enterprise Server-Instanz. Sie können eine beliebige Anzahl an Repositorys migrieren, die einem Benutzer oder einer Organisation auf der Instanz gehören. Vor dem Durchführen einer Migration müssen Sie über Websiteadministratorzugriff auf beide Instanzen verfügen.
- Eine Migration von einer GitHub.com Organisation zu einer GitHub Enterprise Server Instanz. Sie können eine beliebige Anzahl an Repositorys migrieren, die einer Organisation gehören. Bevor Sie eine Migration durchführen, müssen Sie über Administratorzugriff auf die Organisation GitHub.com sowie über Website-Administratorzugriff auf die Zielinstanz verfügen.
- Testausführungen sind Migrationen, die Daten in eine Staging-Instanz importieren. Diese können hilfreich sein, um zu sehen, was geschehen würde, wenn eine Migration auf Ihre GitHub Enterprise Server-Instance angewendet würde. Es wird dringend empfohlen, dass Sie einen Probelauf auf einer Testinstanz durchführen, bevor Sie Daten in Ihre Produktionsinstanz importieren.
Hinweis
Die Verwendung von ghe-migrator wird nicht empfohlen , um eine GitHub Enterprise Server Instanz zwischen Hypervisoren zu übertragen. Stattdessen empfehlen wir, entweder mit GitHub Enterprise Server Backup Utilities eine Sicherung zu erstellen und sie am neuen Speicherort wiederherzustellen oder am neuen Speicherort eine Replik zu erstellen und dann ein Failover auf die Replikat-Appliance durchzuführen. Weitere Informationen findest du unter Konfigurieren von Sicherungen auf deiner Instanz mithilfe von Sicherungshilfsprogrammen, Erstellung eines hochverfügbaren Replikats 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 wird ein Repository innerhalb einer Organisation das Repository und die gesamte Organisation sowie alle dem Repository zugeordneten Benutzer, Teams, Issues und Pull Requests migrieren.
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 Ressourcen.
Hinweis
Forkbeziehungen bleiben nach einer Migration nicht bestehen.
| Einem migrierten Repository zugeordnete Daten | Notizen |
|---|---|
| Benutzer | |
| ** | |
| @mentions | |
| ** der Benutzenden werden umgeschrieben, um dem Ziel zu entsprechen. | |
| Organisationen | Der Name und die Details einer Organisation werden migriert. |
| Repositories | Links zu Git-Strukturen, Blobs, Commits und Zeilen werden neu geschrieben, um dem Ziel zu entsprechen. Interne Repositorys werden als private Repositorys migriert. Der Archivstatus ist nicht festgelegt. |
| Wikis | Alle Wiki-Daten werden migriert. |
| Teams | |
| ** | |
| @mentions | |
| ** der Teams werden umgeschrieben, damit sie dem Ziel entsprechen. | |
| Meilensteine | Zeitstempel werden beibehalten. |
| 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-Bewertungen | 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. |
| Veröffentlichungen | Die Releases-Daten 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. Sie können diese als Bestandteil der Migration deaktivieren. | |
| webhooks | Nur aktive Webhooks werden migriert. |
| Repository-Bereitstellungsschlüssel | Repository-Deployment-Schlüssel werden migriert. |
| Geschützte Branches | Die Einstellungen für geschützte Branches und die zugeordneten Daten werden migriert. |
Informationen zur Migration externer Authentifizierungsdaten
Wenn der Quellspeicherort für Ihre Migration ein GitHub Produkt ist, das LDAP- oder SAML-Authentifizierung verwendet, werden keine externen Authentifizierungsdaten migriert, ghe-migrator die mit Benutzerkonten verknüpft sind. Weitere Informationen zu Authentifizierungsoptionen finden Sie unter GitHub Enterprise Server"Informationen zur Authentifizierung für Ihr Unternehmen" in den GitHub Enterprise Server Dokumenten oder denGitHub Enterprise Cloud Dokumenten.
Wenn Sie zu einer Zielinstanz migrieren und dann die externe Authentifizierung konfigurieren, müssen sich Benutzer mit einem Benutzerkonto bei der Zielinstanz anmelden, das denselben Benutzernamen oder dieselbe Benutzer-ID wie das Konto in der Quellinstanz aufweist. Administratoren können das externe Attribut prüfen, das eine Instanz verwendet, um Benutzerkontonamen aus dem Verwaltungskonsole zuzuordnen. Weitere Informationen finden Sie unter Zugreifen auf die Verwaltungskonsole.