# Экспорт миграционных данных из GitHub.com

Данные миграции можно экспортировать из организации на GitHub.com. Для этого выберите нужные репозитории с помощью API, а затем создайте архив миграции, который можно импортировать в экземпляр GitHub Enterprise Server.

## Подготовка исходной организации к GitHub

1. Убедитесь, что у вас есть [разрешения владельца](/ru/enterprise-server@3.22/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization) в репозиториях исходной организации.

2. [Создание маркера](/ru/enterprise-server@3.22/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) доступа с `repo` областями и `admin:org` областями в GitHub.com.

3. Чтобы свести к минимуму время простоя, создайте список репозиториев, которые необходимо экспортировать из исходного экземпляра. Можно добавить сразу несколько репозиториев для экспорта с помощью текстового файла, в котором указаны URL-адреса каждого репозитория в отдельной строке.

## Экспорт репозиториев организации

> \[!NOTE]
> Связи вилок не сохраняются после миграции.

Чтобы экспортировать данные репозитория из GitHub.com, используйте [API миграций](/ru/rest/migrations).

API миграций в настоящее время доступен в предварительной версии. Это означает, что конечные точки и параметры могут быть изменены в будущем.

## Создание архива миграции

> \[!NOTE]
> Блокировка репозитория предотвращает доступ на запись к репозиторию. Связать новые команды или участников совместной работы с заблокированным репозиторием невозможно.
>
> Если вы выполняете пробный запуск, блокировать репозиторий не нужно. При переносе данных из используемого репозитория GitHub настоятельно рекомендует блокировать репозиторий. Дополнительные сведения см. в разделе [Сведения о миграции ghe-миграции](/ru/enterprise-server@3.22/migrations/using-ghe-migrator/about-ghe-migrator#types-of-migrations).

1. Уведомите членов вашей организации о том, что вы планируете выполнять миграцию. Экспорт может занять несколько минут в зависимости от количества экспортируемых репозиториев. Полная миграция, включая импорт, может занять несколько часов, поэтому рекомендуется выполнить пробный запуск, чтобы определить, сколько времени займет весь процесс. Дополнительные сведения см. в разделе [Сведения о миграции ghe-миграции](/ru/enterprise-server@3.22/migrations/using-ghe-migrator/about-ghe-migrator#types-of-migrations).

2. Запустите миграцию, отправив запрос `POST` к [конечной точке миграции](/ru/rest/migrations#start-an-organization-migration). Что вам понадобится:

   * Маркер доступа для проверки подлинности

   * [Список репозиториев](/ru/rest/repos#list-organization-repositories), которые требуется перенести:

     ```shell
     curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
     -X POST \
     -H "Accept: application/vnd.github+json" \
     -d'{"lock_repositories":true,"repositories":["ORG_NAME/REPO_NAME", "ORG_NAME/REPO_NAME"]}' \
     https://api.github.com/orgs/ORG_NAME/migrations
     ```

   * Если вы хотите заблокировать репозитории перед их переносом, убедитесь, что для параметра `lock_repositories` задано значение `true`. Настоятельно рекомендуется сделать это.

   * Вы можете исключить вложения файлов, передав `exclude_attachments: true` в конечную точку. Вложения файлов могут быть большими и могут без необходимости увеличить размер окончательного архива миграции. Окончательный размер архива должен быть меньше 20 ГБ.

   Этот запрос возвращает уникальный объект `id`, представляющий миграцию. Он потребуется для последующих вызовов API миграций.

3. Отправьте запрос `GET` в [конечную точку статуса миграции](/ru/rest/migrations#get-an-organization-migration-status), чтобы получить статус миграции. Что вам понадобится:

   * Маркер доступа для проверки подлинности
   * Уникальный `id` миграции:

     ```shell
     curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
     -H "Accept: application/vnd.github+json" \
     https://api.github.com/orgs/ORG_NAME/migrations/ID
     ```

   Миграция может находиться в одном из указанных ниже состояний.

   * `pending` — это означает, что миграция еще не запущена.
   * `exporting` — это означает, что миграция находится в процессе выполнения.
   * `exported` — это означает, что миграция успешно завершена.
   * `failed` — это означает, что миграция завершилась сбоем.

4. После экспорта миграции скачайте архив миграции, отправив запрос `GET` к [конечной точке загрузки миграции](/ru/rest/migrations#download-an-organization-migration-archive). Что вам понадобится:
   * Маркер доступа для проверки подлинности
   * Уникальный `id` миграции:

     ```shell
     curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
     -H "Accept: application/vnd.github+json" \
     -L -o migration_archive.tar.gz \
     https://api.github.com/orgs/ORG_NAME/migrations/ID/archive
     ```

5. Архив миграции автоматически удаляется через семь дней. Если вы предпочитаете удалить его раньше, можно отправить запрос `DELETE` в [конечную точку удаления архива миграции](/ru/rest/migrations#delete-an-organization-migration-archive). Что вам понадобится:
   * Маркер доступа для проверки подлинности
   * Уникальный `id` миграции:

     ```shell
     curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" \
     -X DELETE \
     -H "Accept: application/vnd.github+json" \
     https://api.github.com/orgs/ORG_NAME/migrations/ID/archive
     ```

6. Сведения о подготовке архивных данных миграции для импорта в экземпляр GitHub Enterprise Server см. в разделе [Миграция данных на GitHub Enterprise Server](/ru/enterprise-server@3.22/migrations/using-ghe-migrator/migrating-data-to-github-enterprise-server#preparing-the-migrated-data).