# Migrieren von Daten zu GitHub Enterprise Server

Nach dem Generieren eines Migrationsarchivs können Sie die Daten in Ihre Zielinstanz GitHub Enterprise Server importieren. Du kannst die Änderungen auf potenzielle Konflikte überprüfen, bevor du die Änderungen dauerhaft auf deine Zielinstanz anwendest.

## Vorbereiten der migrierten Daten

1. Kopieren Sie mithilfe des [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) Befehls das migrationsarchiv, das von Ihrer Quellinstanz oder Organisation generiert wurde, in Ihr GitHub Enterprise Server Ziel:

   ```shell
   scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
   ```

2. SSH in Ihrer Zielinstanz GitHub Enterprise Server . Weitere Informationen finden Sie unter [Auf die Verwaltungsshell (SSH) zugreifen](/de/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell
   ssh -p 122 admin@HOSTNAME
   ```

3. Stelle sicher, dass das Migrationsarchiv über ausreichende Leseberechtigungen verfügt.

   ```shell
   chmod 644 /home/admin/MIGRATION-GUID.tar.gz
   ```

4. Führe den Befehl `ghe-migrator prepare` aus, um das Archiv für den Import auf der Zielinstanz vorzubereiten, und generiere eine neue Migrations-GUID, die du in den nachfolgenden Schritten verwendest:

   ```shell
   ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
   ```

   * Führe `ghe-migrator prepare` erneut aus, und rufe eine neue Migrations-GUID ab, um einen neuen Importversuch zu starten.
   * Um anzugeben, wo Migrationsdateien gestaget werden sollen, füge dem Befehl `--staging-path=/full/staging/path` an. Wird standardmäßig auf `/data/user/tmp` festgelegt.

## Liste mit Migrationskonflikten generieren

1. Verwende den `ghe-migrator conflicts`-Befehl mit der Migrations-GUID, um eine *conflicts.csv*-Datei zu generieren:

   ```shell
   ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
   ```

   * Wenn keine Konflikte gemeldet werden, können Sie die Daten sicher importieren.

2. Verwende bei Konflikten den [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp)-Befehl, um *conflicts.csv* auf deinen lokalen Computer zu kopieren:

   ```shell
   scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
   ```

3. Fahre mit [Beheben von Migrationskonflikten oder Einrichten benutzerdefinierter Zuordnungen](#resolving-migration-conflicts-or-setting-up-custom-mappings) fort.

## Migrationskonflikte überprüfen

1. Öffne [conflicts.csv](https://en.wikipedia.org/wiki/Comma-separated_values#Application_support) mit einem Text-Editor oder einer *CSV-kompatiblen Tabellensoftware*.
2. Überprüfe die Datei *conflicts.csv*, um sicherzustellen, dass beim Import die richtigen Aktionen ausgeführt werden. Berücksichtige dabei die Anleitung für die folgenden Beispiele und Verweistabellen.

Die *conflicts.csv*-Datei enthält eine *Migrationskarte* von Konflikten und empfohlene Aktionen. Eine Migrationskarte listet auf, welche Daten von der Quelle migriert werden und wie die Daten auf das Ziel angewendet werden.

| `model_name`   | `source_url`                                           | `target_url`                                           | `recommended_action` |
| -------------- | ------------------------------------------------------ | ------------------------------------------------------ | -------------------- |
| `user`         | `https://example-gh.source/octocat`                    | `https://example-gh.target/octocat`                    | `map`                |
| `organization` | `https://example-gh.source/octo-org`                   | `https://example-gh.target/octo-org`                   | `map`                |
| `repository`   | `https://example-gh.source/octo-org/widgets`           | `https://example-gh.target/octo-org/widgets`           | `rename`             |
| `team`         | `https://example-gh.source/orgs/octo-org/teams/admins` | `https://example-gh.target/orgs/octo-org/teams/admins` | `merge`              |

Jede Zeile in *conflicts.csv* bietet die folgenden Informationen:

| Name                 | BESCHREIBUNG                                                              |
| -------------------- | ------------------------------------------------------------------------- |
| `model_name`         | Der Typ der zu ändernden Daten.                                           |
| `source_url`         | Die Quell-URL der Daten.                                                  |
| `target_url`         | Die erwartete Ziel-URL der Daten.                                         |
| `recommended_action` | Bevorzugte Aktion, die `ghe-migrator` beim Importieren von Daten ausführt |

### Mögliche Zuordnungen für jeden Datensatztyp

Es gibt einige verschiedene Zuordnungsaktionen, die `ghe-migrator` beim Übertragen von Daten ausführen kann:

| `action`        | BESCHREIBUNG                                                                                                                                                                                                                                                                                  | Entsprechende Modelle                 |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- |
| `import`        | (Standard) Daten von der Quellinstanz werden auf die Zielinstanz importiert.                                                                                                                                                                                                                  | Alle Datensatztypen                   |
| `map`           | Anstatt basierend auf den Quelldaten ein neues Modell zu erstellen, wird ein vorhandener Datensatz im Ziel verwendet. Dies ist nützlich zum Importieren eines Repositorys in eine vorhandene Organisation oder Zuordnen von Benutzeridentitäten im Ziel zu Benutzeridentitäten in der Quelle. | Benutzer\*innen, Organisationen       |
| `rename`        | Daten von der Quellinstanz werden umbenannt und anschließend auf die Zielinstanz kopiert.                                                                                                                                                                                                     | Benutzer, Organisationen, Repositorys |
| `map_or_rename` | Bei Vorhandensein der Zielinstanz sollte die Zuordnung zur Zielinstanz erfolgen. Andernfalls sollte das importierte Modell umbenannt werden.                                                                                                                                                  | Benutzer                              |
| `merge`         | Daten von der Quellinstanz werden mit vorhandenen Daten auf der Zielinstanz kombiniert.                                                                                                                                                                                                       | Teams                                 |

**Es wird dringend empfohlen, die *conflicts.csv*-Datei zu überprüfen und `ghe-migrator audit` zu verwenden, um sicherzustellen, dass die geeigneten Aktionen ausgeführt werden.** Wenn alles wie gewünscht aussieht, können Sie fortfahren.

## Migrationskonflikte beheben und benutzerdefinierte Zuordnungen einrichten

Wenn du der Meinung bist, dass `ghe-migrator` eine nicht ordnungsgemäße Änderung vornimmt, kannst du Korrekturen vornehmen, indem du die Daten in *conflicts.csv* änderst. Du kannst an allen Zeilen in *conflicts.csv* Änderungen vornehmen.

Angenommen, du bemerkst, dass der Benutzer `octocat` aus der Quelle dem Ziel `octocat` zugeordnet wird.

| `model_name` | `source_url`                        | `target_url`                        | `recommended_action` |
| ------------ | ----------------------------------- | ----------------------------------- | -------------------- |
| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/octocat` | `map`                |

Du kannst den Benutzer einem anderen Benutzer auf der Zielinstanz zuordnen. Angenommen, du weißt, dass `octocat` in der Zielversion eigentlich `monalisa` sein sollte. Du kannst die `target_url`-Spalte in *conflicts.csv* so ändern, dass auf `monalisa` verwiesen wird:

| `model_name` | `source_url`                        | `target_url`                         | `recommended_action` |
| ------------ | ----------------------------------- | ------------------------------------ | -------------------- |
| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `map`                |

Weiteres Beispiel: Wenn du das `octo-org/widgets`-Repository in `octo-org/amazing-widgets` in der Zielinstanz umbenennen möchtest, ändere `target_url` in `octo-org/amazing-widgets` und `recommend_action` in `rename`.

| `model_name` | `source_url`                                 | `target_url`                                         | `recommended_action` |
| ------------ | -------------------------------------------- | ---------------------------------------------------- | -------------------- |
| `repository` | `https://example-gh.source/octo-org/widgets` | `https://example-gh.target/octo-org/amazing-widgets` | `rename`             |

### Benutzerdefinierte Zuordnungen hinzufügen

Während einer Migration geschieht es häufig, dass migrierte Benutzer andere Benutzernamen auf der Zielinstanz als auf der Quellinstanz besitzen.

Mit einer Liste der Benutzernamen von der Quellinstanz und einer Liste der Benutzernamen von der Zielinstanz kannst du eine CSV-Datei mit benutzerdefinierten Zuordnungen erstellen und anschließend anwenden, um sicherzustellen, dass der Benutzername und Inhalt jedes Benutzers am Ende einer Migration richtig zugeordnet werden.

Du kannst schnell eine CSV-Datei der migrierten Benutzer\*innen im CSV-Format erstellen, die erforderlich ist, um benutzerdefinierte Zuordnungen mithilfe des `ghe-migrator audit`-Befehls anzuwenden:

```shell
ghe-migrator audit -m user -g MIGRATION-GUID > users.csv
```

Nun kannst du diese CSV-Datei bearbeiten und die neue URL für jede*n Benutzer*in eingeben, die du zuordnen oder umbenennen möchtest. Aktualisiere dann die vierte Spalte, damit `map` bzw. `rename` entsprechend vorliegt.

Um beispielsweise den Benutzer `octocat` in `monalisa` im Ziel `https://example-gh.target` umzubenennen, erstelle eine Zeile mit dem folgenden Inhalt:

| `model_name` | `source_url`                        | `target_url`                         | `state`  |
| ------------ | ----------------------------------- | ------------------------------------ | -------- |
| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `rename` |

Mit demselben Prozess kannst du Zuordnungen für jeden Datensatz erstellen, der benutzerdefinierte Zuordnungen unterstützt. Weitere Informationen findest du in der [Tabelle zu möglichen Zuordnungen für Datensätze](#possible-mappings-for-each-record-type).

### Geänderte Migrationsdaten anwenden

1. Nachdem du Änderungen vorgenommen hast, verwende den Befehl [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp), um deine bearbeitete *conflicts.csv*-Datei (oder eine beliebige andere *.csv*-Zuordnungsdatei im richtigen Format) auf die Zielinstanz anzuwenden:

   ```shell
   scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
   ```

2. Ordne die Migrationsdaten mithilfe des `ghe-migrator map`-Befehls neu zu. Übergib dazu den Pfad zu deiner bearbeiteten *.csv*-Datei und die Migrations-GUID:

   ```shell
   ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
   ```

3. Wenn der `ghe-migrator map -i conflicts.csv -g MIGRATION-GUID`-Befehl berichtet, dass noch immer Konflikte bestehen, führe den Vorgang zum Beheben von Migrationskonflikten erneut durch.

## Anwenden der importierten Daten auf GitHub Enterprise Server

1. SSH in Ihrer Zielinstanz GitHub Enterprise Server . Weitere Informationen finden Sie unter [Auf die Verwaltungsshell (SSH) zugreifen](/de/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell
   ssh -p 122 admin@HOSTNAME
   ```

2. Starte den Importvorgang mit dem Befehl `ghe-migrator import`. du benötigst Folgendes:

   * Deine Migrations-GUID. Weitere Informationen finden Sie unter [Vorbereiten der migrierten Daten für den Import in GitHub Enterprise Server](#preparing-the-migrated-data).
   * Ihre personal access token für die Authentifizierung. Die personal access token Verwendung erfolgt nur für die Authentifizierung als Websiteadministrator und erfordert keinen bestimmten Bereich oder keine bestimmten Berechtigungen. Weitere Informationen finden Sie unter [Verwalten deiner persönlichen Zugriffstoken](/de/enterprise-server@3.22/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).

   ```shell
   $ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN

   > Starting GitHub::Migrator
   > Import 100% complete /
   ```

   * Um anzugeben, wo Migrationsdateien gestaget werden sollen, füge dem Befehl `--staging-path=/full/staging/path` an. Wird standardmäßig auf `/data/user/tmp` festgelegt.

## Migrationsdaten überprüfen

Mit `ghe-migrator audit` wird standardmäßig jeder Datensatz zurückgegeben. Es erlaubt dir auch, die Datensätze zu filtern nach:

* Die Arten von Datensätzen
* Der Zustand der Datensätze.

Die Datensatztypen stimmen mit denen in den [migrierten Daten](/de/enterprise-server@3.22/migrations/using-ghe-migrator/about-ghe-migrator#migrated-data) überein.

## Filter für Datensatztypen

| Eintragstyp                                        | Filter-Name                   |
| -------------------------------------------------- | ----------------------------- |
| Benutzer                                           | `user`                        |
| Organisationen                                     | `organization`                |
| Repositories                                       | `repository`                  |
| Teams                                              | `team`                        |
| Meilensteine                                       | `milestone`                   |
| Probleme                                           | `issue`                       |
| Issue-Kommentare                                   | `issue_comment`               |
| Pull Requests                                      | `pull_request`                |
| Pull-Request-Bewertungen                           | `pull_request_review`         |
| Commit-Kommentare                                  | `commit_comment`              |
| Pull-Request-Review-Kommentare                     | `pull_request_review_comment` |
| Veröffentlichungen                                 | `release`                     |
| Bei Pull Requests oder Issues ergriffene Maßnahmen | `issue_event`                 |
| Geschützte Branches                                | `protected_branch`            |

## Filter für Aufzeichnungszustände

| Datensatzzustand | BESCHREIBUNG                                       |
| ---------------- | -------------------------------------------------- |
| `export`         | Der Datensatz wird exportiert.                     |
| `import`         | Der Datensatz wird importiert.                     |
| `map`            | Der Datensatz wird zugeordnet.                     |
| `rename`         | Der Datensatz wird umbenannt.                      |
| `merge`          | Der Datensatz wird zusammengeführt.                |
| `exported`       | Der Datensatz wurde erfolgreich exportiert.        |
| `imported`       | Der Datensatz wurde erfolgreich importiert.        |
| `mapped`         | Der Datensatz wurde erfolgreich zugeordnet.        |
| `renamed`        | Der Datensatz wurde erfolgreich umbenannt.         |
| `merged`         | Der Datensatz wurde erfolgreich zusammengeführt.   |
| `failed_export`  | Fehler beim Export des Datensatzes.                |
| `failed_import`  | Der Datensatz konnte nicht importiert werden.      |
| `failed_map`     | Fehler beim Zuordnen des Datensatzes.              |
| `failed_rename`  | Der Datensatz konnte nicht umbenannt werden.       |
| `failed_merge`   | Der Datensatz konnte nicht zusammengeführt werden. |

## Überwachte Datensätze filtern

Mit dem Befehl `ghe-migrator audit` kannst du unter Verwendung des Flags `-m` nach dem Datensatztyp filtern. Ebenso kannst du mit dem Flag `-s` nach dem Importstatus filtern. Der Befehl sieht wie folgt aus:

```shell
ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID
```

Wenn du beispielsweise alle erfolgreich importierten Organisationen und Teams anzeigen möchtest, würdest du Folgendes eingeben:

```shell
$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed
```

**Wir empfehlen dringend, jeden fehlgeschlagenen Import zu überprüfen.** Dazu gibst du Folgendes ein:

```shell
$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed
```

Wenn Sie Bedenken bezüglich fehlgeschlagener Importe haben, können Sie uns kontaktieren, indem Sie uns besuchen [GitHub Enterprise-Support](https://support.github.com).

## Abschließen des Imports am GitHub Enterprise Server

Nachdem deine Migration auf die Zielinstanz angewendet wurde und du die Migration überprüft hast, entsperrst du die Repositorys und löschst sie von der Quellinstanz. Vor dem Löschen deiner Quelldaten solltest du etwa zwei Wochen warten, um sicherzugehen, dass alles erwartungsgemäß funktioniert.

## Repositorys auf der Zielinstanz entsperren

1. SSH in Ihre GitHub Enterprise Server-Instance. Wenn deine Instanz mehrere Knoten umfasst, wenn z. B. Hochverfügbarkeit oder Georeplikation konfiguriert ist, wird SSH im primären Knoten konfiguriert. Wenn du einen Cluster verwendest, kannst du SSH in einen beliebigen Knoten einfügen. Ersetzen Sie HOSTNAME durch den Hostnamen Ihrer Instanz bzw. durch den Hostnamen oder die IP-Adresse eines Knotens. Weitere Informationen finden Sie unter [Auf die Verwaltungsshell (SSH) zugreifen](/de/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell copy
   ssh -p 122 admin@HOSTNAME
   ```
2. Entsperre alle importierten Repositorys mit dem `ghe-migrator unlock`-Befehl. Du benötigst Deine Migrations-GUID:

```shell
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
```

> \[!WARNING]
> Wenn Ihr Repository GitHub ActionsWorkflows enthält, die den `schedule`Auslöser verwenden, werden die Workflows nach dem Import nicht automatisch ausgeführt. Um die geplanten Workflows wieder zu starten, pushen Sie einen Commit in das Repository. Weitere Informationen finden Sie unter [Ereignisse zum Auslösen von Workflows](/de/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).

## Repositorys auf der Quellinstanz entsperren

Nach Abschluss der Migration sollten Sie die Repositorys für die Quelle entsperren.

### Entsperren von Repositorys aus einer Organisation auf GitHub.com

Um die Repositories in einer GitHub.com-Organisation zu entsperren, senden Sie eine `DELETE`-Anfrage an [den Endpunkt zum Entsperren der Migration](/de/rest/migrations#unlock-an-organization-repository). du benötigst Folgendes:

* Dein Zugriffstoken für die Authentifizierung
* Die eindeutige `id` der Migration
* den Namen des zu entsperrenden Repositorys

```shell
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock
```

### Löschen von Repositorys aus einer Organisation auf GitHub.com

Nachdem Sie die Repositories der GitHub.com-Organisation entsperrt haben, sollten Sie jedes Repository löschen, das Sie zuvor über [den Endpunkt zum Löschen von Repositorys](/de/enterprise-server@3.22/rest/repos/repos#delete-a-repository) migriert haben. du benötigst dein Zugriffstoken für die Authentifizierung:

```shell
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  https://api.github.com/repos/ORG-NAME/REPO_NAME
```

### Entsperren von Repositorys aus einer GitHub Enterprise Server Instanz

1. SSH in Ihre GitHub Enterprise Server-Instance. Wenn deine Instanz mehrere Knoten umfasst, wenn z. B. Hochverfügbarkeit oder Georeplikation konfiguriert ist, wird SSH im primären Knoten konfiguriert. Wenn du einen Cluster verwendest, kannst du SSH in einen beliebigen Knoten einfügen. Ersetzen Sie HOSTNAME durch den Hostnamen Ihrer Instanz bzw. durch den Hostnamen oder die IP-Adresse eines Knotens. Weitere Informationen finden Sie unter [Auf die Verwaltungsshell (SSH) zugreifen](/de/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell copy
   ssh -p 122 admin@HOSTNAME
   ```
2. Entsperre alle importierten Repositorys mit dem `ghe-migrator unlock`-Befehl. Du benötigst Deine Migrations-GUID:

```shell
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
```