将组织从 GitHub.com 迁移到 GitHub Enterprise Cloud

关于使用 GitHub Enterprise Importer 的组织迁移

迁移到 GitHub Enterprise Cloud 包括在 GitHub.com 上的账户之间的迁移，以及（如果您采用数据驻留）迁移到您企业的 GHE.com 子域名。

您可以通过 GitHub CLI 或 API 来运行迁移。

GitHub CLI 简化了迁移流程，推荐给大多数客户。对自定义需求较高的高级客户可以使用 API，构建自己的 GitHub Enterprise Importer 集成。

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

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

先决条件

我们强烈建议您先进行迁移试运行，并在试运行后尽快完成正式迁移。要了解有关试运行的更多信息，请参阅 GitHub 产品之间迁移概述。
确保您了解将要迁移的数据以及 Importer 已知的支持限制。更多信息，请参阅关于 GitHub 产品之间的迁移。
虽然不是强制要求，但我们建议在正式迁移期间暂停工作。Importer 不支持增量迁移，因此迁移期间所做的任何更改都不会被迁移。如果您选择在正式迁移期间不暂停工作，则需要手动迁移这些更改。
对于源组织，您必须是组织所有者或拥有迁移者角色。更多信息，请参阅管理 GitHub 产品之间迁移的访问权限。
对于目标企业账户，您必须是企业所有者。
组织迁移最多可迁移包含多达 5,000 个仓库的组织。如果组织包含超过 5,000 个仓库，请遵循从 GitHub.com 迁移仓库到 GitHub Enterprise Cloud 的指南。

步骤 0：准备使用 GitHub GraphQL API

要进行 GraphQL 查询，您需要编写自己的脚本或使用诸如 Insomnia 之类的 HTTP 客户端。

想了解更多关于开始使用 GitHub GraphQL API 的信息，包括如何进行身份验证，请参阅使用 GraphQL 发起调用。

您需要将所有 GraphQL 查询发送到迁移的目标。如果您迁移到具有数据驻留要求的 GitHub Enterprise Cloud，请确保将查询发送到您企业 GHE.com 子域的端点。

步骤 1：获取迁移目标的企业 ID

作为 GitHub.com 上的企业所有者，使用以下查询获取您希望拥有迁移后组织的企业账户的 ID。您需要企业 ID 来标识迁移目标。

query(
  $slug: String!
){
  enterprise (slug: $slug)
  {
    slug
    id
  }
}

查询变量	描述
`slug`	企业账户的 slug，可通过查看企业的 URL 来确定，形式为 `https://github.com/enterprises/SLUG` 或 `https://SLUG.ghe.com`。

步骤 2：开始组织迁移

当您启动迁移时，单个组织及其相关数据会迁移到您指定的目标企业中的全新组织。

mutation startOrganizationMigration (
  $sourceOrgUrl: URI!,
  $targetOrgName: String!,
  $targetEnterpriseId: ID!,
  $sourceAccessToken: String!,
	$targetAccessToken: String!
){
  startOrganizationMigration( input: {
    sourceOrgUrl: $sourceOrgUrl,
    targetOrgName: $targetOrgName,
    targetEnterpriseId: $targetEnterpriseId,
    sourceAccessToken: $sourceAccessToken,
		targetAccessToken: $targetAccessToken
  }) {
    orgMigration {
      id
    }
  }
}

查询变量	描述
`sourceOrgUrl`	源组织的 URL，例如 `https://github.com/octo-org`。
`targetOrgName`	新组织希望使用的名称。目标平台上不得有其他组织使用相同名称。
`targetEnterpriseId`	您希望在其内创建新组织的企业 ID，由步骤 2 返回。
`sourceAccessToken`	源组织的个人访问令牌（经典版）。有关要求，请参阅管理 GitHub 产品之间迁移的访问权限。
`targetAccessToken`	目标企业的个人访问令牌（经典版）。

在下一步中，您将使用 startOrganizationMigration 变更返回的迁移 ID 来检查迁移状态。

步骤 3：检查迁移状态

要检测任何迁移失败并确保迁移正常运行，您可以使用 getMigration 查询来查询已创建的 OrganizationMigration（们），以查看迁移状态。

查询将返回状态，告知迁移是否为 queued（排队中）、in progress（进行中）、failed（失败）或 completed（已完成），以及还有多少仓库等待迁移。如果迁移失败，Importer 将提供失败原因。

query (
  $id: ID!
){
  node( id: $id ) {
    ... on OrganizationMigration {
      id
			sourceOrgUrl
			targetOrgName
      state
      failure_reason
      remaining_repositories_count
      total_repositories_count
    }
  }
}

查询变量	描述
`id`	您的迁移的 `id`。

步骤 1：安装 GitHub CLI 的 GEI 扩展

如果这是您第一次迁移，您需要安装 GitHub CLI 的 GEI 扩展。有关 GitHub CLI 的更多信息，请参阅关于 GitHub CLI。

安装 GitHub CLI。有关 GitHub CLI 的安装说明，请参阅 GitHub CLI 仓库。

注意

您需要 GitHub CLI 版本 2.4.0 或更高。可使用 gh --version 命令检查已安装的版本。

安装 GEI 扩展。

Shell

gh extension install github/gh-gei

gh extension install github/gh-gei

任何需要 GEI 扩展帮助的情况下，都可以在命令后使用 --help 标志。例如，gh gei --help 将列出所有可用命令，gh gei migrate-repo --help 将列出 migrate-repo 命令的所有选项。

步骤 2：更新 GitHub CLI 的 GEI 扩展

GEI 扩展每周更新一次。为确保使用最新版本，请更新该扩展。

gh extension upgrade github/gh-gei

步骤 3：设置环境变量

在使用 GEI 扩展迁移到 GitHub Enterprise Cloud 之前，您必须创建可访问源组织和目标企业的个人访问令牌（经典版），然后将这些个人访问令牌（经典版）设置为环境变量。

创建并记录满足组织迁移源组织身份验证所有要求的个人访问令牌（经典版）。更多信息，请参阅管理 GitHub 产品之间迁移的访问权限。
创建并记录满足目标企业身份验证所有要求的个人访问令牌（经典版）。
为个人访问令牌（经典版）设置环境变量，将下面命令中的 TOKEN 替换为您在上面记录的个人访问令牌（经典版）。使用 GH_PAT 作为目标企业的令牌，使用 GH_SOURCE_PAT 作为源组织的令牌。
- 如果您使用 Terminal，请使用 export 命令。
  Shell
```
export GH_PAT="TOKEN"
export GH_SOURCE_PAT="TOKEN"
```
```
export GH_PAT="TOKEN"
export GH_SOURCE_PAT="TOKEN"
```
- 如果您使用 PowerShell，请使用 $env 命令。
  Shell
```
$env:GH_PAT="TOKEN"
$env:GH_SOURCE_PAT="TOKEN"
```
```
$env:GH_PAT="TOKEN"
$env:GH_SOURCE_PAT="TOKEN"
```
如果您正在迁移到具有数据驻留的 GitHub Enterprise Cloud，为方便起见，请为您企业的 基础 API URL 设置环境变量。

确保将 SUBDOMAIN 替换为您企业的子域。例如，如果企业子域为 acme，则 TARGET_API_URL 的值应为 https://api.acme.ghe.com。
- 如果您使用 Terminal，请使用 export 命令。
  Shell
```
export TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
```
```
export TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
```
- 如果您使用 PowerShell，请使用 $env 命令。
  Shell
```
$env:TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
```
```
$env:TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
```
您将在使用 GitHub CLI 运行的命令中，通过 --target-api-url 选项使用此变量。

步骤 4：迁移您的组织

要迁移组织，请使用 gh gei migrate-org 命令。

Shell

gh gei migrate-org --github-source-org SOURCE --github-target-org DESTINATION --github-target-enterprise ENTERPRISE

gh gei migrate-org --github-source-org SOURCE --github-target-org DESTINATION --github-target-enterprise ENTERPRISE

注意

如果您迁移到 GHE.com，请添加 --target-api-url TARGET-API-URL，其中 TARGET-API-URL 是您企业子域的基础 API URL。例如：https://api.octocorp.ghe.com。

将上述命令中的占位符替换为以下值。

占位符	值
SOURCE	源组织的名称
DESTINATION	新组织希望使用的名称。目标平台上不得有其他组织使用相同名称。
ENTERPRISE	目标企业的 slug，可通过查看企业账户的 URL 确定，形式为 `https://github.com/enterprises/SLUG` 或 `https://SLUG.ghe.com`。

步骤 5：验证迁移并检查错误日志

步骤 4：验证迁移并检查错误日志

迁移完成后，我们建议您检查迁移日志仓库。更多信息，请参阅访问 GitHub Enterprise Importer 的迁移日志。

最后，我们建议您对组织及迁移后的仓库进行完整性检查。

工具导航

本文内容