# GitHub.com からの移行データのエクスポート

API を使用して移行するリポジトリを選択し、GitHub.com インスタンスにインポートできる移行アーカイブを生成することで、GitHub Enterprise Server 上の Organization から移行データをエクスポートできます。

## GitHub でソース Organization を準備する

1. ソース Organization のリポジトリに対する[所有者のアクセス許可](/ja/enterprise-server@3.22/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization)があることを確認します。

2. [
   ](/ja/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 からリポジトリ データをエクスポートするには、[Migrations API](/ja/rest/migrations) を使用します。

移行APIは現在プレビュー期間です。すなわち、エンドポイントとパラメータは将来変更されることがあります。

## 移行アーカイブの生成

> \[!NOTE]
> リポジトリをロックすると、リポジトリへのすべての書き込みアクセスができなくなります。 ロックされたリポジトリには、新しいTeamやコラボレータを関連づけることはできません。
>
> トライアル実行をしているなら、リポジトリをロックする必要はありません。 使用中のリポジトリからデータを移行する場合、GitHub はリポジトリをロックすることを強くお勧めします。 詳しくは、「[ghe-migrator について](/ja/enterprise-server@3.22/migrations/using-ghe-migrator/about-ghe-migrator#types-of-migrations)」をご覧ください。

1. 組織のメンバーに移行を実施することを通知します。 エクスポートには、対象のリポジトリ数に応じて数分がかかることがあります。 インポートを含む完全な移行には何時間もかかる可能性があるため、完全な処理にかかる時間を判断するためにまず試行することをおすすめします。 詳しくは、「[ghe-migrator について](/ja/enterprise-server@3.22/migrations/using-ghe-migrator/about-ghe-migrator#types-of-migrations)」をご覧ください。

2. `POST` 要求を[移行エンドポイント](/ja/rest/migrations#start-an-organization-migration)に送信して、移行を開始します。 必要なものは次のとおりです。

   * 認証のためのアクセストークン。

   * 移行する[リポジトリのリスト](/ja/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 GB 未満である必要があります。

   この要求により、移行を表す一意の `id` が返されます。 これは次の移行 API の呼び出しに必要となります。

3. 移行の状態を取得するには、`GET` リクエストを [移行ステータスエンドポイント](/ja/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. 移行がエクスポートされたら、<c1>の移行アーカイブダウンロードエンドポイントに<c0 />リクエストを送信してダウンロードします。 必要なものは次のとおりです。
   * 認証のためのアクセストークン。
   * 移行の一意の `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. 移行アーカイブは 7 日間経過すると自動的に削除されます。 より早く削除する場合は、`DELETE`に「移行アーカイブ削除エンドポイント」への要求を送信できます。 必要なものは次のとおりです。
   * 認証のためのアクセストークン。
   * 移行の一意の `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 へのデータの移行](/ja/enterprise-server@3.22/migrations/using-ghe-migrator/migrating-data-to-github-enterprise-server#preparing-the-migrated-data)」を参照してください。