如果选择使用 API，则需要编写自己的脚本或使用 HTTP 客户端（如 [Insomnia](https://insomnia.rest/)）。您可以在GitHub和[REST API 入门](/zh/enterprise-server@3.18/rest/using-the-rest-api/getting-started-with-the-rest-api)中详细了解如何开始使用[](/zh/enterprise-server@3.18/graphql/guides/forming-calls-with-graphql)的 API。若要使用 API 将存储库从 GitHub Enterprise Server 其中 GitHub Enterprise Cloud 迁移到，需要： 1. 为源组织和目标组织分别创建一个 personal access token 2. 获取 `ownerId` 上目标组织的 GitHub Enterprise Cloud 3. 通过 GitHub“GraphQL API” 设置迁移源，以标识从何处迁移 4. 对于要迁移的每个存储库重复以下步骤。 * 使用 REST API 为你的 GitHub Enterprise Server 实例存储库生成迁移存档 * 将迁移归档文件上传到 GitHub 可访问的位置 * 使用迁移目标的 GraphQL API 开始迁移，并传入存档 URL * 通过 GraphQL API 检查迁移状态 * 验证迁移并检查错误日志

若要查看使用 API 的说明，请使用页面顶部的工具切换器。

若要查看使用 GitHub CLI 的说明，请使用页面顶部的工具切换器。

## 步骤 1。创建你的 personal access token 1. 创建并记录一个 personal access token (classic)，用于在 GitHub Enterprise Cloud 上为目标组织进行身份验证，确保令牌满足所有要求。有关详细信息，请参阅“[管理 GitHub 产品之间迁移的访问权限](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#creating-a-personal-access-token-for-github-enterprise-importer)”。 2. 创建并记录一个 personal access token，用于对源组织进行身份验证的，确保此令牌也满足所有相同的要求。 ## 步骤 2：获取目标组织的 `ownerId` 作为 GitHub Enterprise Cloud 中的组织所有者，请使用 `GetOrgInfo` 查询为要拥有已迁移存储库的组织返回 `ownerId`（也称为组织 ID）。需要使用 `ownerId` 来标识迁移目标。 #### `GetOrgInfo` 查询 ```graphql query( $login: String! ){ organization (login: $login) { login id name databaseId } } ``` | 查询变量 | 说明 | | ------- | ----- | | `login` | 组织名称。 | #### `GetOrgInfo` 响应 ```json { "data": { "organization": { "login": "Octo", "id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=", "name": "Octo-org", "databaseId": 5610 } } } ``` 在此示例中，`MDEyOk9yZ2FuaXphdGlvbjU2MTA=` 是组织 ID 或 `ownerId`，在下一步中会用到它。 ## 步骤 3：设置 blob 存储执行存储库迁移时，必须将存储库数据存储在可访问的位置 GitHub Enterprise Importer 。可执行以下操作来实现此做法： * 在 GHES 实例（GHES 3.16\*\*\*\* 版及更高版本）上使用本地存储 * 使用 Blob 存储提供程序 ### 使用本地存储 (GHES 3.16+) 使用本地存储来运行迁移时，归档数据会写入你的 GitHub Enterprise Server 实例的磁盘中，而无需依赖云存储提供商。 * 如果没有防火墙规则阻止来自 GitHub Enterprise Server 的出口流量，GitHub Enterprise Importer 可以自动从 GitHub Enterprise Server 检索存储的存档。 * 如果你确实有防火墙规则并且不想允许访问 GitHub Enterprise Importer，可以将存档数据上传到 GitHub-owned blob storage 以便 GitHub Enterprise Importer 访问。要手动执行此操作，请参阅本文 API 版本中的[将迁移存档上传到 GitHub 拥有的 Blob 存储](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/migrating-repositories-from-github-enterprise-server-to-github-enterprise-cloud?tool=api#uploading-your-migration-archives-to-github-owned-blob-storage)。 1. 在 GitHub Enterprise Server 上的管理帐户中，在任一页面的右上角，单击“”。 2. 在“ 站点管理”边栏中，单击“管理控制台”\*\*\*\*。 3. 登录到管理控制台。 4. 在左边栏中，单击“Migrations”\*\*\*\*。 5. 单击“Enable GitHub Migrations”\*\*\*\*。 6. 在“Migrations Storage”下，单击“Local Storage”\*\*\*\*。 7. 单击“保存设置”。执行迁移时，请监视 GitHub Enterprise Server 上的磁盘空间。迁移存档将在 7 天后自动删除。若要释放空间，可以使用 [适用于组织迁移的 REST API 终结点](/zh/enterprise-server@3.18/rest/migrations/orgs#delete-an-organization-migration-archive)删除存档。 ### 使用 Blob 存储提供程序 GitHub Enterprise Server如果实例位于防火墙后面，则可能需要使用外部云服务设置 Blob 存储。首先，必须使用受支持的提供商设置 blob 存储。之后，如果你使用云提供商，必须在管理控制台或 GitHub CLI 中配置存储提供商的凭据。 GitHub CLI 支持以下 Blob 存储提供程序： * Amazon Web Services (AWS) S3 * Azure Blob 存储 > \[!NOTE] > 仅当使用 GitHub Enterprise Server 版本 3.8 或更高版本时，才需要配置 Blob 存储。如果使用GitHub Enterprise Server版本 3.7 或更低版本，请跳到[步骤 4：在中GitHub Enterprise Cloud设置迁移源](#step-4-set-up-a-migration-source-in-github-enterprise-cloud)。 > > 迁移具有大型 Git 源或元数据的存储库需要 blob 存储。如果使用 GitHub Enterprise Server 版本 3.7 或更低版本，将无法执行 Git 源或元数据导出超过 2GB 的迁移。若要执行这些迁移，请更新到 GitHub Enterprise Server 版本 3.8 或更高版本。 #### 设置 AWS S3 存储桶在 AWS 中，设置 S3 Bucket。有关详细信息，请参阅 AWS 文档中的[创建 Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)。还需要具有以下权限的 AWS 访问密钥和密钥： ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:DeleteObject", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::github-migration-bucket", "arn:aws:s3:::github-migration-bucket/*" ] } ] } ``` > \[!NOTE] > 迁移完成后，GitHub Enterprise Importer 不会从 AWS 中删除存档。为了降低存储成本，建议配置在一段时间后自动删除存档。有关详细信息，请参阅 AWS 文档中的[ Bucket 生命周期配置](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)。 #### 设置 Azure Blob 存储帐户在 Azure 中，创建存储帐户并记下连接字符串。有关详细信息，请参阅 Microsoft Docs 中的[管理存储帐户访问密钥](https://learn.microsoft.com/en-gb/azure/storage/common/storage-account-keys-manage?tabs=azure-portal#regenerate-access-keys)。 > \[!NOTE] > 迁移完成后，GitHub Enterprise Importer 不会从 Azure Blob 存储中删除存档。为了降低存储成本，建议配置为在一段时间后自动删除存档。有关详细信息，请参阅 Microsoft Docs 中的[通过自动管理数据生命周期来优化成本](https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-overview)。 #### 在管理控制台的你的 GitHub Enterprise Server 实例中配置 Blob 存储设置 AWS S3 存储存储桶或Azure Blob 存储帐户后，请在其中管理控制台你的 GitHub Enterprise Server 实例配置 Blob 存储。有关该操作的详细信息管理控制台，请参阅 [从管理控制台管理实例](/zh/enterprise-server@3.18/admin/administering-your-instance/administering-your-instance-from-the-web-ui)。 1. 使用 GitHub Enterprise Server 上的管理员账户，在任意页面的右上角，点击。 2. 如果尚未在“网站管理员”页面上，请在左上角单击 **“网站管理员**”。 1. 在“ 站点管理”边栏中，单击“管理控制台”\*\*\*\*。 3. 登录到 .管理控制台 4. 在顶部导航栏中，单击“设置”。 5. 在 **“迁移**”下，单击“ **启用 GitHub 迁移**”。 6. （可选）若要导入配置的 GitHub Actions存储设置，请选择 **“操作”中的“复制存储设置**”。有关详细信息，请参阅[使用 Azure Blob 存储启用 GitHub Actions](/zh/enterprise-server@3.18/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-azure-blob-storage) 和[使用 Amazon S3 存储启用 GitHub Actions](/zh/enterprise-server@3.18/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-amazon-s3-storage)。 > \[!NOTE] > 复制存储设置后，仍可能需要更新云存储帐户的配置才能使用 GitHub Enterprise Importer。具体而言，必须确保 GitHub允许列出's IP 地址。有关详细信息，请参阅“[管理 GitHub 产品之间迁移的访问权限](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)”。 7. 如果不从GitHub Actions中导入存储设置，请选择**Azure Blob 存储**或 **Amazon S3** 并填写所需的详细信息。 > \[!NOTE] > 如果使用 Amazon S3，必须将“AWS 服务 URL”设置为存储桶所在 AWS 区域的标准端点。例如，如果存储桶位于 `eu-west-1` 区域中，则“AWS 服务 URL”应为 `https://s3.eu-west-1.amazonaws.com`。实例 GitHub Enterprise Server 的网络必须允许访问此主机。不支持网关端点，例如 `bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com`。有关网关端点的详细信息，请参阅 AWS 文档中的 [Amazon S3 的网关端点](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)。 8. 单击“测试存储设置”。 9. 单击“保存设置”。 #### 允许网络访问如果您已在存储帐户上配置了防火墙规则，请确保您已允许访问迁移目标的 IP 范围。请参阅“[管理 GitHub 产品之间迁移的访问权限](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)”。 ## 步骤 4：在 GitHub Enterprise Cloud 中设置迁移源可以使用 `createMigrationSource` 查询设置迁移源。需要提供从 `GetOrgInfo` 查询收集的 `ownerId` 或组织 ID。你的迁移源是 GitHub Enterprise Server 上的组织。 ### `createMigrationSource` 突变 ```graphql mutation createMigrationSource($name: String!, $url: String!, $ownerId: ID!) { createMigrationSource(input: {name: $name, url: $url, ownerId: $ownerId, type: GITHUB_ARCHIVE}) { migrationSource { id name url type } } } ``` > \[!NOTE] > 请确保对 `type` 使用 `GITHUB_ARCHIVE`。 | 查询变量 | 说明 | | --------- | ---------------------------------- | | `name` | 迁移源的名称。此名称仅供你自己参考，因此可以使用任何字符串。 | | `ownerId` | GitHub Enterprise Cloud 上组织的组织 ID。 | | `url` | 你的 GitHub Enterprise Server 实例的 URL。此 URL 不需要能从 GitHub Enterprise Cloud 访问。 ### `createMigrationSource` 响应 ```json { "data": { "createMigrationSource": { "migrationSource": { "id": "MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ", "name": "GHES Source", "url": "https://my-ghes-hostname.com", "type": "GITHUB_ARCHIVE" } } } } ``` 在此示例中，`MS_kgDaACRjZTY5NGQ1OC1mNDkyLTQ2NjgtOGE1NS00MGUxYTdlZmQwNWQ` 是迁移源 ID，我们将在后面的步骤中使用。 ## 步骤 5：在你的 GitHub Enterprise Server 实例上生成迁移归档文件你将使用 REST API 在 GitHub Enterprise Server 中启动两个“迁移”：一个用于生成仓库 Git 源代码的存档，另一个用于生成仓库元数据（如问题和拉取请求）的存档。若要生成 Git 源代码归档包，请向 `POST` 发出 `https://HOSTNAME/api/v3/orgs/ORGANIZATION/migrations` 请求，并将 `HOSTNAME` 替换为你的 GitHub Enterprise Server 实例的主机名，将 `ORGANIZATION` 替换为贵组织的登录名。在正文中，指定要迁移的单个存储库。请求应类似于： ```http POST /api/v3/orgs/acme-corp/migrations HTTP/1.1 Accept: application/vnd.github+json Authorization: Bearer Content-Type: application/json Host: github.acmecorp.net { "repositories": ["repository_to_migrate"], "exclude_metadata": true } ``` 若要生成元数据存档，请向同一 URL 发送具有以下正文的类似请求： ```json { "repositories": ["repository_to_migrate"], "exclude_git_data": true, "exclude_releases": false, "exclude_owner_projects": true } ``` 这两个 API 调用中的每一个都将返回一个 JSON 响应，其中包括已开始的迁移的 ID。 ```http HTTP/1.1 201 Created { "id": 123, // ... } ``` 有关详细信息，请参阅[开始组织迁移](/zh/enterprise-server@3.18/rest/migrations/orgs#start-an-organization-migration)。生成存档可能需要一段时间，具体取决于数据量。可以通过“获取组织迁移状态”API 定期查看两个迁移的状态，直到迁移的 `state` 变为 `exported`。 ```http GET /api/v3/orgs/acme-corp/migrations/123 HTTP/1.1 Accept: application/vnd.github+json Authorization: Bearer Host: github.acmecorp.net HTTP/1.1 200 OK Content-Type: application/json { "id": 123, "state": "exported", // ... } ``` 有关详细信息，请参阅[获取组织迁移状态](/zh/enterprise-server@3.18/rest/migrations/orgs#get-an-organization-migration-status)。 > \[!NOTE] > 如果迁移变为 `failed` 状态而不是 `exported` 状态，请尝试重新开始迁移。如果迁移反复失败，建议使用 `ghe-migrator` 而不是 API 生成存档。 > > 按照[从企业导出迁移数据](/zh/enterprise-server@3.18/migrations/using-ghe-migrator/exporting-migration-data-from-github-enterprise-server)中的步骤操作，仅向迁移添加一个存储库。完成此过程后，你将拥有一个包含 Git 源和元数据的迁移存档，此时可以转到本文中的步骤 6。迁移的 `state` 变为 `exported` 后，可以使用“下载组织迁移存档”API 提取迁移的 URL。 ```http GET /api/v3/orgs/acme-corp/migrations/123/archive HTTP/1.1 Accept: application/vnd.github+json Authorization: Bearer Host: github.acmecorp.net HTTP/1.1 302 Found Location: https://media.github.acmecorp.net/migrations/123/archive/cca2ebe9-7403-4ffa-9b6a-4c9e16c94410?token=AAAAABEWE7JP4H2HACKEGMTDOYRC6 ``` API 将返回带有 `302 Found` 标头的 `Location` 响应，该标头重定向到可下载存档所在的 URL。下载这两个文件：一个用于 Git 源，一个用于元数据。有关详细信息，请参阅[下载组织迁移存档](/zh/enterprise-server@3.18/rest/migrations/orgs#download-an-organization-migration-archive)。完成两个迁移并下载存档后，可以转到下一步骤。 ## 步骤 6：上传迁移存档若要将数据导入GitHub Enterprise Cloud，您必须使用我们的 GraphQL API，将每个仓库的两个归档文件（Git 源数据和元数据）从您的计算机传输到GitHub。如果使用的是 GitHub Enterprise Server 3.7 或更低版本，则必须首先为可访问 GitHub的存档生成 URL。大多数客户选择将存档上传到云提供商的 blob 存储服务（例如 Amazon S3 或 Azure Blob 存储），然后为每个存档生成一个短期 URL。如果使用的是 GitHub Enterprise Server 3.8 或更高版本，则实例将上传存档并生成 URL。上一步中的 `Location` 标头将返回短期 URL。你可能需要将 GitHub 的 IP 范围加入允许列表。有关详细信息，请参阅“[管理 GitHub 产品之间迁移的访问权限](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)”。 ### 将迁移存档上传到 GitHub-owned blob storage 如果您使用 GitHub-owned blob storage，请按照以下流程将归档文件上传到 GitHub-owned blob storage： 1. 通过提交 POST 请求创建多部分上传 2. 将多个部分中高达 100 MB 的存档作为 PATCH 请求上传 3. 提交 PUT 请求以完成上传 #### 1.创建多部分上传你将提交 POST 请求以执行以下操作： ```http https://uploads.github.com/organizations/{organization_id}/gei/archive/blobs/uploads ``` 包括具有此存档名称和大小的 JSON 正文，如下所示。对于所有上传，内容类型可以保留为 `"application/octet-stream"`。 ```json { "content_type": "application/octet-stream", "name": "git-archive.tar.gz", "size": 262144000 } ``` 这将返回 JSON 对象响应，如下所示： ```json { "guid": "363b2659-b8a3-4878-bfff-eed4bcb54d35", "node_id": "MA_kgDaACQzNjNiMjY1OS1iOGEzLTQ4NzgtYmZmZi1lZWQ0YmNiNTRkMzU", "name": "git-archive.tar.gz", "size": 33287, "uri": "gei://archive/363b2659-b8a3-4878-bfff-eed4bcb54d35", "created_at": "2024-11-13T12:35:45.761-08:00" } ``` 此 URI 表示上传的存档，在开始存储库迁移时将用于对迁移排队。在下一步中，响应还将包含用于使用 PATCH 请求上传文件部分的响应标头中的位置： ```http /organizations/{organization_id}/gei/archive/blobs/uploads?part_number=1&guid=&upload_id= ``` #### 2.上传多个部分中的存档使用上一个响应标头中的位置，使用 PATCH 请求在每个部分上传最多 100 MB 的文件，确保在请求正文中上传原始数据，而无需使用多部分表单。如果文件的最后一部分小于 100 MB，则仅上传最后一个请求中的剩余字节： ```http https://uploads.github.com/{location} ``` 这将返回响应标头中具有以下位置的空响应正文： ```http /organizations/{organization_id}/gei/archive/blobs/uploads?part_number=2&guid=&upload_id= ``` 重复此操作，直到上传完成。确保一次读取最多 100 MB 的文件，并将请求提交到具有递增 `part_number` 值的新位置值。 #### 3.完成上传将 PUT 请求提交到上一步中具有空正文的“last path”值，向 GitHub 拥有的存储进行上传的操作现已完成。可以使用此初始 POST 请求的 GUID 构造 GEI URI，格式如下： ```http gei://archive/{guid} ``` ## 步骤 7：开始存储库迁移开始迁移时，单个存储库及其随附的数据将迁移到你标识的全新 GitHub 存储库。如果要从同一源组织一次移动多个存储库，则可以将多个迁移排入队列。最多可以同时运行 5 个存储库迁移。 ### `startRepositoryMigration` 突变 ```graphql mutation startRepositoryMigration ( $sourceId: ID!, $ownerId: ID!, $repositoryName: String!, $continueOnError: Boolean!, $accessToken: String!, $githubPat: String!, $gitArchiveUrl: String!, $metadataArchiveUrl: String!, $sourceRepositoryUrl: URI!, $targetRepoVisibility: String! ){ startRepositoryMigration( input: { sourceId: $sourceId, ownerId: $ownerId, repositoryName: $repositoryName, continueOnError: $continueOnError, accessToken: $accessToken, githubPat: $githubPat, targetRepoVisibility: $targetRepoVisibility gitArchiveUrl: $gitArchiveUrl, metadataArchiveUrl: $metadataArchiveUrl, sourceRepositoryUrl: $sourceRepositoryUrl, }) { repositoryMigration { id migrationSource { id name type } sourceUrl } } } ``` | 查询变量 | 说明 | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | `sourceId` | 从 `createMigrationSource` 突变返回的迁移源 `id`。 | | `ownerId` | 组织在 GitHub Enterprise Cloud 上的组织 ID。 | | `repositoryName` | 组织在 GitHub Enterprise Cloud 上拥有的任何存储库当前未使用的自定义唯一存储库名称。迁移完成或停止时，将在此存储库中创建一个错误记录问题。 | | `continueOnError` | 迁移设置，允许在遇到不会导致迁移失败的错误时继续迁移。必须为 `true` 或 `false`。强烈建议将 `continueOnError` 设置为 `true`，以便继续迁移，除非 Importer 无法移动 Git 源，或 Importer 已断开连接且无法重新连接以完成迁移。 | | `githubPat` | 目标组织在 personal access token 上的 GitHub Enterprise Cloud。 | | `accessToken` | 源的 personal access token。 | | `targetRepoVisibility` | 新存储库的可见性。必须为 `private`、`public` 或 `internal`。如果未设置，则存储库将作为专用存储库迁移。 | `gitArchiveUrl` | 用于访问您的 Git 源代码归档的 GitHub Enterprise Cloud URL。 `metadataArchiveUrl` | 可供 GitHub Enterprise Cloud 访问的元数据存档 URL。 `sourceRepositoryUrl` | \| 你的 GitHub Enterprise Server 实例上存储库的 URL。这是必需的，但 GitHub Enterprise Cloud 不会直接与 GitHub Enterprise Server 实例通信。有关 personal access token 要求，请参阅 [管理 GitHub 产品之间迁移的访问权限](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#required-scopes-for-personal-access-tokens)。在下一步中，将使用从 `startRepositoryMigration` 突变返回的迁移 ID 来检查迁移状态。 ## 步骤 8：检查迁移状态要检测任何迁移失败并确保迁移正常工作，可以使用 `getMigration` 查询检查迁移状态。还可以使用 `getMigrations` 检查多个迁移的状态。 `getMigration` 查询将返回状态，让你知道迁移状态是 `queued`、`in progress`、`failed` 还是 `completed`。如果迁移失败，Importer 将提供失败原因。 #### `getMigration` 查询 ```graphql query ( $id: ID! ){ node( id: $id ) { ... on Migration { id sourceUrl migrationSource { name } state failureReason } } } ``` | 查询变量 | 说明 | | ---- | ------------------------------------------------------------------------------- | | `id` | [`startRepositoryMigration` 突变](#startrepositorymigration-mutation)返回的迁移的 `id`。 | ## 步骤 9：验证迁移并检查错误日志要完成迁移，建议检查“迁移日志”问题。此问题在目标存储库中的 GitHub 上创建。 ![标题为“迁移日志”的问题的屏幕截图。问题中的第二个注释包括迁移的日志。](/assets/images/help/github-enterprise-importer/migration-log-issue.png) 最后，建议查看已迁移的存储库以进行完整性检查。

## 步骤 1：安装 GEI extension of the GitHub CLI 如果这是第一次迁移，需要安装 GEI extension of the GitHub CLI。有关 GitHub CLI 的详细信息，请参阅“[关于 GitHub CLI](/zh/enterprise-server@3.18/github-cli/github-cli/about-github-cli)”。此外，也可以从 `github/gh-gei` 存储库的[版本页面](https://github.com/github/gh-gei/releases)下载一个独立的二进制文件。可以直接运行此二进制文件，无需使用前缀 `gh`。 1. 安装 GitHub CLI。有关 GitHub CLI 的安装说明，请参阅 [GitHub CLI 存储库](https://github.com/cli/cli#installation)。 > \[!NOTE] > 需要 GitHub CLI 版本 2.4.0 或更高版本。可以使用 `gh --version` 命令检查已安装的版本。 2. 安装 GEI extension。 ```shell copy gh extension install github/gh-gei ``` 每当需要 GEI extension 的帮助时，都可以将 `--help` 标志与命令一起使用。例如，`gh gei --help` 将列出所有可用命令，`gh gei migrate-repo --help` 将列出 `migrate-repo` 命令的所有可用选项。 ## 步骤 2：更新 GEI extension of the GitHub CLI GEI extension 每周更新一次。为了确保使用的是最新版本，请更新扩展。 ```shell gh extension upgrade github/gh-gei ``` ## 步骤 3：设置环境变量在使用 GEI extension 迁移到 GitHub Enterprise Cloud 之前，必须创建可以访问源和目标组织的 personal access token，然后将 personal access token 设置为环境变量。 1. 创建并记录一个 personal access token (classic)，用于在 GitHub Enterprise Cloud 上为目标组织进行身份验证，确保令牌满足所有要求。有关详细信息，请参阅“[管理 GitHub 产品之间迁移的访问权限](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#creating-a-personal-access-token-for-github-enterprise-importer)”。 2. 创建并记录一个 personal access token，用于对源组织进行身份验证的，确保此令牌也满足所有相同的要求。 3. 为 personal access token 设置环境变量，将以下命令中的 TOKEN 替换为上面记录的 personal access token。将 `GH_PAT` 用于目标组织，并将 `GH_SOURCE_PAT` 用于源组织。 * 如果使用终端，请使用 `export` 命令。 ```shell copy export GH_PAT="TOKEN" export GH_SOURCE_PAT="TOKEN" ``` * 如果使用 PowerShell，请使用 `$env` 命令。 ```shell copy $env:GH_PAT="TOKEN" $env:GH_SOURCE_PAT="TOKEN" ``` 4. 如果要迁移到带有数据驻留权的 GitHub Enterprise Cloud，为方便起见，请为企业 **的基本 API URL** 设置环境变量。确保将 `SUBDOMAIN` 替换为您企业的子域。例如，如果企业的子域为 `acme`，则 `TARGET_API_URL` 值为 `https://api.acme.ghe.com`。 * 如果使用终端，请使用 `export` 命令。 ```shell copy export TARGET_API_URL="https://api.SUBDOMAIN.ghe.com" ``` * 如果使用 PowerShell，请使用 `$env` 命令。 ```shell copy $env:TARGET_API_URL="https://api.SUBDOMAIN.ghe.com" ``` 你将将此变量与在命令中运行`--target-api-url`的选项一起使用GitHub CLI。 ## 步骤 4：设置 blob 存储 ### 使用 GitHub-owned blob storage 迁移仓库如果您不想配置客户自有的 Blob 存储账户并向 GitHub Enterprise Importer 授予访问权限来存储您的仓库存档，则可以使用 GitHub-owned blob storage 迁移仓库。为此，必须运行 v1.9.0（或更高版本）。GEI extension of the GitHub CLI GitHub-owned blob storage 不需要其他设置，在运行 GEI extension of the GitHub CLI 命令时可用作选项。出于安全考虑， GitHub-owned blob storage 显式只写，无法从中 GitHub-owned blob storage 下载。迁移完成后，系统将立即删除存储库存档。如果上传了存档但未在迁移中使用，则存档将在 7 天后删除。当您对 GitHub-owned blob storage 使用 CLI 标志时，系统会自动将仓库归档文件导出到管理控制台中配置的目标位置，上传到 GitHub 所有的存储，并导入到您的迁移目标中。使用 GitHub-owned blob storage 时，建议配置本地存储。请参阅[使用本地存储 (GHES 3.16+)](#using-local-storage-ghes-316-1)。 ### 使用客户拥有的 Blob 存储来迁移存储库必须将存储库数据存储在 GitHub 可以访问的位置。如果 GitHub Enterprise Server 实例位于防火墙后方，则可能需要使用外部云服务设置 Blob 存储。首先，必须使用受支持的提供商设置 blob 存储。然后，如果使用云提供商，必须在管理控制台或 GitHub CLI 中配置存储提供程序的凭据。 GitHub CLI 支持以下 Blob 存储提供程序： * Amazon Web Services (AWS) S3 * Azure Blob 存储 * GHES 实例（GHES 3.16 版及更高版本）上的本地存储\*\*\*\*。建议将此选项用于 GitHub-owned blob storage。 ### 设置 AWS S3 存储桶在 AWS 中，设置 S3 Bucket。有关详细信息，请参阅 AWS 文档中的[创建 Bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)。还需要具有以下权限的 AWS 访问密钥和密钥： ```json { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListBucket", "s3:DeleteObject", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::github-migration-bucket", "arn:aws:s3:::github-migration-bucket/*" ] } ] } ``` > \[!NOTE] > 迁移完成后，GitHub Enterprise Importer 不会从 AWS 中删除存档。为了降低存储成本，建议配置在一段时间后自动删除存档。有关详细信息，请参阅 AWS 文档中的[ Bucket 生命周期配置](https://docs.aws.amazon.com/AmazonS3/latest/userguide/how-to-set-lifecycle-configuration-intro.html)。 ### 设置 Azure Blob 存储帐户在 Azure 中，创建存储帐户并记下连接字符串。有关详细信息，请参阅 Microsoft Docs 中的[管理存储帐户访问密钥](https://learn.microsoft.com/en-gb/azure/storage/common/storage-account-keys-manage?tabs=azure-portal#regenerate-access-keys)。 > \[!NOTE] > 迁移完成后，GitHub Enterprise Importer 不会从 Azure Blob 存储中删除存档。为了降低存储成本，建议配置为在一段时间后自动删除存档。有关详细信息，请参阅 Microsoft Docs 中的[通过自动管理数据生命周期来优化成本](https://learn.microsoft.com/en-us/azure/storage/blobs/lifecycle-management-overview)。 ### 使用本地存储 (GHES 3.16+) 使用本地存储来运行迁移时，归档数据会写入你的 GitHub Enterprise Server 实例的磁盘中，而无需依赖云存储提供商。 * 如果没有防火墙规则阻止来自 GitHub Enterprise Server 的出口流量，GitHub Enterprise Importer 可以自动从 GitHub Enterprise Server 检索存储的存档。 * 如果你确实有防火墙规则并且不想允许访问 GitHub Enterprise Importer，可以将存档数据上传到 GitHub-owned blob storage 以便 GitHub Enterprise Importer 访问。要手动执行此操作，请参阅本文 API 版本中的[将迁移存档上传到 GitHub 拥有的 Blob 存储](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/migrating-repositories-from-github-enterprise-server-to-github-enterprise-cloud?tool=api#uploading-your-migration-archives-to-github-owned-blob-storage)。 1. 在 GitHub Enterprise Server 上的管理帐户中，在任一页面的右上角，单击“”。 2. 在“ 站点管理”边栏中，单击“管理控制台”\*\*\*\*。 3. 登录到管理控制台。 4. 在左边栏中，单击“Migrations”\*\*\*\*。 5. 单击“Enable GitHub Migrations”\*\*\*\*。 6. 在“Migrations Storage”下，单击“Local Storage”\*\*\*\*。 7. 单击“保存设置”。执行迁移时，请监视 GitHub Enterprise Server 上的磁盘空间。迁移存档将在 7 天后自动删除。若要释放空间，可以使用 [适用于组织迁移的 REST API 终结点](/zh/enterprise-server@3.18/rest/migrations/orgs#delete-an-organization-migration-archive)删除存档。 ### 配置 blob 存储凭据如果将 Blob 存储设置为使用 **云服务提供商**（而不是本地存储），则必须在 GitHub 中配置该存储提供商的凭据： * 如果您使用的是 GitHub Enterprise Server 3.8 或更高版本，请在管理控制台中配置您的凭据。 * 如果您使用的是 GitHub Enterprise Server 3.7 或更低版本，请在 GitHub CLI 中配置凭据。 #### 在管理控制台的你的 GitHub Enterprise Server 实例中配置 Blob 存储 > \[!NOTE] > 仅当您使用管理控制台 3.8 或更高版本时，才需要在 GitHub Enterprise Server 中配置 Blob 存储。如果您使用的是 3.7 或更低版本，请改为在 GitHub CLI 中配置凭据。设置 AWS S3 存储存储桶或Azure Blob 存储帐户后，请在其中管理控制台你的 GitHub Enterprise Server 实例配置 Blob 存储。有关该操作的详细信息管理控制台，请参阅 [从管理控制台管理实例](/zh/enterprise-server@3.18/admin/administering-your-instance/administering-your-instance-from-the-web-ui)。 1. 使用 GitHub Enterprise Server 上的管理员账户，在任意页面的右上角，点击。 2. 如果尚未在“网站管理员”页面上，请在左上角单击 **“网站管理员**”。 1. 在“ 站点管理”边栏中，单击“管理控制台”\*\*\*\*。 3. 登录到 .管理控制台 4. 在顶部导航栏中，单击“设置”。 5. 在 **“迁移**”下，单击“ **启用 GitHub 迁移**”。 6. （可选）若要导入配置的 GitHub Actions存储设置，请选择 **“操作”中的“复制存储设置**”。有关详细信息，请参阅[使用 Azure Blob 存储启用 GitHub Actions](/zh/enterprise-server@3.18/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-azure-blob-storage) 和[使用 Amazon S3 存储启用 GitHub Actions](/zh/enterprise-server@3.18/admin/managing-github-actions-for-your-enterprise/enabling-github-actions-for-github-enterprise-server/enabling-github-actions-with-amazon-s3-storage)。 > \[!NOTE] > 复制存储设置后，仍可能需要更新云存储帐户的配置才能使用 GitHub Enterprise Importer。具体而言，必须确保 GitHub允许列出's IP 地址。有关详细信息，请参阅“[管理 GitHub 产品之间迁移的访问权限](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)”。 7. 如果不从GitHub Actions中导入存储设置，请选择**Azure Blob 存储**或 **Amazon S3** 并填写所需的详细信息。 > \[!NOTE] > 如果使用 Amazon S3，必须将“AWS 服务 URL”设置为存储桶所在 AWS 区域的标准端点。例如，如果存储桶位于 `eu-west-1` 区域中，则“AWS 服务 URL”应为 `https://s3.eu-west-1.amazonaws.com`。实例 GitHub Enterprise Server 的网络必须允许访问此主机。不支持网关端点，例如 `bucket.vpce-0e25b8cdd720f900e-argc85vg.s3.eu-west-1.vpce.amazonaws.com`。有关网关端点的详细信息，请参阅 AWS 文档中的 [Amazon S3 的网关端点](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html)。 8. 单击“测试存储设置”。 9. 单击“保存设置”。 ### 在 GitHub CLI 中配置您的 Blob 存储凭据 > \[!NOTE] > 如果您使用的是 GitHub CLI 3.7 或更低版本，则只需在 GitHub Enterprise Server 中配置 Blob 存储凭据。如果您使用的是 3.8 或更高版本，请改为在管理控制台中配置 Blob 存储。 > > 如果您在 GitHub CLI 中配置了 Blob 存储凭据，则将无法执行 Git 源或元数据导出超过 2GB 的迁移操作。若要执行这些迁移，请升级到 GitHub Enterprise Server 3.8 或更高版本。 #### 在 GitHub CLI 中配置 AWS S3 凭证准备好运行迁移后，你将需要向 GitHub CLI 提供 AWS 凭据：区域、访问密钥、密钥和会话令牌（如果需要）。可以将它们作为参数传递，或设置名为 `AWS_REGION`、`AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY` 和 `AWS_SESSION_TOKEN` 的环境变量。你还需要使用 `--aws-bucket-name` 参数传入 S3 Bucket 的名称。 #### 在 GitHub CLI 中配置 Azure Blob 存储账户凭据准备好运行迁移时，可以将连接字符串作为参数传递到 GitHub CLI，或使用名为 `AZURE_STORAGE_CONNECTION_STRING` 的环境变量将其传入。 ### 允许网络访问如果您已在存储帐户上配置了防火墙规则，请确保您已允许访问迁移目标的 IP 范围。请参阅“[管理 GitHub 产品之间迁移的访问权限](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations)”。 ## 步骤 5：生成迁移脚本如果要一次性将多个存储库迁移到 GitHub Enterprise Cloud，请使用 GitHub CLI 生成迁移脚本。生成的脚本将包含迁移命令的列表（每个存储库一个）。 > \[!NOTE] > 生成脚本会输出 PowerShell 脚本。如果使用的是终端，则需要以 `.ps1` 文件扩展名输出脚本，并安装适用于 [Mac](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.2) 或 [Linux](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.2) 的 PowerShell 才能运行它。如果要迁移单个存储库，请跳到下一步。 ### 生成迁移脚本必须在可以访问你的 GitHub Enterprise Server 实例的 API 的计算机上执行此步骤。如果可以从浏览器访问实例，那么计算机具有正确的访问权限。若要生成迁移脚本，请运行 `gh gei generate-script` 命令。对于 GitHub Enterprise Server 3.8 或更高版本，或搭配 Azure Blob 存储使用 3.7 或更低版本的情况，请使用以下标志： ```shell copy gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL ``` 如果您使用的是 3.7 或更低版本的 GitHub Enterprise Server 且配合 AWS S3，请使用以下参数： ```shell copy gh gei generate-script --github-source-org SOURCE \ --github-target-org DESTINATION \ --output FILENAME \ --ghes-api-url GHES-API-URL \ --aws-bucket-name AWS-BUCKET-NAME ``` #### 占位符将上述命令中的占位符替换为以下值。 | 占位符 | 值 | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 源 | 源组织名称 | | 目标 | 目标组织的名称 | | FILENAME | 生成的迁移脚本的文件名

如果使用终端，请使用 `.ps1` 文件扩展名，因为生成的脚本需要 PowerShell 才能运行。可以安装适用于 [Mac](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-macos?view=powershell-7.2) 或 [Linux](https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-linux?view=powershell-7.2) 的 PowerShell。 | | GHES-API-URL | 你的 GitHub Enterprise Server 实例的 API 的 URL，如 `https://myghes.com/api/v3` | | AWS-BUCKET-NAME | AWS S3 桶的桶名称 | #### 其他参数 | 参数 | 说明 | | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `--download-migration-logs` | 下载每个已迁移存储库的迁移日志。有关迁移日志的详细信息，请参阅“[访问 GitHub Enterprise Importer 的迁移日志](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/accessing-your-migration-logs-for-github-enterprise-importer#downloading-all-the-repository-migration-logs-for-a-migration-script)”。 | | `--lock-source-repo` | 迁移时锁定源存储库。 | | **警告：** 锁定源存储库可防止进一步更改，并可能会中断工作流。如果确定此选项合适，则建议仅使用此选项。有关详细信息，请参阅“[关于锁定的存储库](/zh/enterprise-server@3.18/migrations/overview/about-locked-repositories)”。 | | | `--no-ssl-verify` | 如果你的 GitHub Enterprise Server 实例使用自签名或无效的 SSL 证书，请使用 `--no-ssl-verify` 标志。使用此标志时，GitHub CLI 在仅从实例中提取数据时跳过验证 SSL 证书的步骤。所有其他调用都会验证 SSL。 | | `--skip-releases` | 如果存储库的发布数据超过 10 GB，则无法迁移发布。使用 `--skip-releases` 标志即可在不迁移发布的情况下迁移存储库。 | | `--target-api-url TARGET-API-URL` | 如果要迁移到 GHE.com，请添加 `--target-api-url TARGET-API-URL`，其中 TARGET-API-URL 是企业的子域的基本 API URL。例如：`https://api.octocorp.ghe.com`。 | | `--use-github-storage` | 使用 GitHub-owned blob storage 中间 Blob 存储解决方案执行存储库迁移。 | ### 查看迁移脚本生成脚本后，查看文件，并根据需要编辑脚本。 * 如果有任何不想迁移的存储库，请删除或注释掉相应的行。 * 如果希望任何存储库在目标组织中具有不同的名称，请更新相应 `--target-repo` 标志的值。 * 如果要更改新存储库的可见性，请更新相应 `--target-repo-visibility` 标志的值。默认情况下，脚本设置与源存储库相同的可见性。如果存储库的发布数据超过 10 GB，则无法迁移发布。使用 `--skip-releases` 标志即可在不迁移发布的情况下迁移存储库。如果将 GEI 作为一个独立的二进制文件而不是 GitHub CLI 的一个扩展下载，则需要更新所生成的脚本，以运行此二进制文件而不是 `gh gei`。 ## 步骤 6：迁移存储库可以使用迁移脚本迁移多个存储库，也可以使用 `gh gei migrate-repo` 命令迁移单个存储库。迁移存储库时，GEI extension of the GitHub CLI 会执行以下步骤： 1. 连接到你的 GitHub Enterprise Server 实例，并为每个仓库生成两个迁移归档文件，一个用于 Git 源，另一个用于元数据 2. 将迁移存档上传到所选的 blob 存储提供程序 3. 在 GitHub Enterprise Cloud 中启动迁移，使用存储在你的 Blob 存储提供商处的存档 URL 4. 从本地计算机中删除迁移存档 ### 迁移多个存储库如果在运行脚本之前从 GitHub Enterprise Server 3.7 或更早版本迁移，则必须设置其他环境变量以向 Blob 存储提供程序进行身份验证。 * 对于 Azure Blob 存储，请将 `AZURE_STORAGE_CONNECTION_STRING` 设置为 Azure 存储帐户的连接字符串。仅支持使用存储帐户访问密钥的连接字符串。不支持使用共享访问签名 (SAS) 的连接字符串。有关存储帐户访问密钥的详细信息，请参阅 Azure 文档中的[管理存储帐户访问密钥](https://learn.microsoft.com/en-gb/azure/storage/common/storage-account-keys-manage?tabs=azure-portal#regenerate-access-keys)。 * 对于 AWS S3，请设置以下环境变量。 * `AWS_ACCESS_KEY_ID`：存储桶的访问密钥 ID * `AWS_SECRET_ACCESS_KEY`：存储桶的密钥 * `AWS_REGION`：存储桶所在的 AWS 区域 * `AWS_SESSION_TOKEN`：会话令牌（如果使用的是 AWS 临时凭据）（请参阅 AWS 文档中的[将临时凭据用于 AWS 资源](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_use-resources.html)）若要迁移多个存储库，请运行生成的脚本。将以下命令中的 FILENAME 替换为生成脚本时提供的文件名。 * 如果使用终端，请使用 `./`。 ```shell copy ./FILENAME ``` * 如果使用 PowerShell，请使用 `.\`。 ```shell copy .\FILENAME ``` ### 迁移单个存储库必须在可以访问你的 GitHub Enterprise Server 实例的 API 的计算机上执行此步骤。如果可以从浏览器访问实例，那么计算机具有正确的访问权限。要迁移单个存储库，请使用 `gh gei migrate-repo` 命令。如果使用的是 GitHub Enterprise Server 3.8 或更高版本，请使用以下标志： ```shell copy gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME --ghes-api-url GHES-API-URL ``` 如果要从 GitHub Enterprise Server 3.7 或更早版本迁移并使用 Azure Blob 存储作为 Blob 存储提供程序，请使用以下标志进行身份验证： ```shell copy gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \ --ghes-api-url GHES-API-URL --azure-storage-connection-string "AZURE_STORAGE_CONNECTION_STRING" ``` 如果要从 GitHub Enterprise Server 3.7 或更早版本迁移并使用 Amazon S3 作为 Blob 存储提供程序，请使用以下标志进行身份验证： ```shell copy gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME \ --ghes-api-url GHES-API-URL --aws-bucket-name "AWS-BUCKET-NAME" ``` #### 占位符将上述命令中的占位符替换为以下值。 | 占位符 | 值 | | ---------------------------------- | ------------------------------------------------------------------------ | | 源 | 源组织名称 | | CURRENT-NAME | 要迁移的存储库的名称 | | 目标 | 目标组织的名称 | | NEW-NAME | 希望已迁移的存储库具有的名称 | | GHES-API-URL | 你的 GitHub Enterprise Server 实例的 API 的 URL，如 `https://myghes.com/api/v3` | | AZURE\_STORAGE\_CONNECTION\_STRING | Azure 存储帐户的连接字符串。

请确保为连接字符串加引号，其中包含可能由 shell 解释的字符。 | | AWS-BUCKET-NAME | AWS S3 桶的桶名称 | #### 其他参数 | 参数 | 说明 | | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | `--lock-source-repo` | 迁移时锁定源存储库。有关详细信息，请参阅“[关于锁定的存储库](/zh/enterprise-server@3.18/migrations/overview/about-locked-repositories)”。 | | `--no-ssl-verify` | 如果你的 GitHub Enterprise Server 实例使用自签名或无效的 SSL 证书，请使用 `--no-ssl-verify` 标志。使用此标志时，GitHub CLI 在仅从实例中提取数据时跳过验证 SSL 证书的步骤。所有其他调用都会验证 SSL。 | | `--skip-releases` | 如果存储库的发布数据超过 10 GB，则无法迁移发布。使用 `--skip-releases` 标志即可在不迁移发布的情况下迁移存储库。 | | `--target-api-url TARGET-API-URL` | 如果要迁移到 GHE.com，请添加 `--target-api-url TARGET-API-URL`，其中 TARGET-API-URL 是企业的子域的基本 API URL。例如：`https://api.octocorp.ghe.com`。 | | `--target-repo-visibility TARGET-VISIBILITY` | 默认情况下，存储库都以专用可见性进行迁移。若要设置可见性，可以添加 `--target-repo-visibility` 标志，以指定 `private`、`public` 或 `internal`。如果要迁移到具有托管用户的企业，则公共存储库不可用。 | | `--use-github-storage` | 使用 GitHub-owned blob storage 中间 Blob 存储解决方案执行存储库迁移。 | #### 中止迁移如果要取消迁移，请使用 `abort-migration` 命令，将 MIGRATION-ID 替换为从 `migrate-repo` 返回的 ID。 ```shell copy gh gei abort-migration --migration-id MIGRATION-ID ``` ## 步骤 7：验证迁移并检查错误日志迁移完成后，建议查看迁移日志。有关详细信息，请参阅“[访问 GitHub Enterprise Importer 的迁移日志](/zh/enterprise-server@3.18/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/accessing-your-migration-logs-for-github-enterprise-importer)”。如果源存储库包含规则集，并且被它们阻止，请参阅 [为存储库迁移设置规则集旁路](/zh/enterprise-cloud@latest/migrations/troubleshooting/setting-ruleset-bypasses-for-repository-migrations)。建议查看已迁移的存储库以进行完整性检查。迁移完成后，建议从存储容器中删除存档。如果你计划完成更多迁移，请删除由 ADO2GH extension 放入你的存储容器中的存档。如果已完成迁移，则可以删除整个容器。