关于使用 GitHub Enterprise Importer 进行仓库迁移
迁移到 GitHub Enterprise Cloud 包括在 GitHub.com 上的账户之间的迁移,以及(如果您采用数据驻留)迁移到您企业的 GHE.com 子域名。
您可以通过 GitHub CLI 或 API 来运行迁移。
GitHub CLI 简化了迁移流程,推荐给大多数客户。对自定义需求较高的高级客户可以使用 API,构建自己的 GitHub Enterprise Importer 集成。
先决条件
- 我们强烈建议您先进行迁移试运行,并在试运行后尽快完成正式迁移。要了解有关试运行的更多信息,请参阅 GitHub 产品之间迁移概述。
- 确保您了解将要迁移的数据以及 Importer 已知的支持限制。更多信息,请参阅 关于 GitHub 产品之间的迁移。
- 虽然不是强制要求,但我们建议在正式迁移期间暂停工作。Importer 不支持增量迁移,因此迁移期间所做的任何更改都不会被迁移。如果您选择在正式迁移期间不暂停工作,则需要手动迁移这些更改。
- 在源组织和目标组织中,您必须是组织所有者或被授予迁移者角色。有关更多信息,请参阅 管理 GitHub 产品之间迁移的访问权限。
步骤 0:准备使用 GitHub GraphQL API
要进行 GraphQL 查询,您需要编写自己的脚本或使用诸如 Insomnia 之类的 HTTP 客户端。
想了解更多关于开始使用 GitHub GraphQL API 的信息,包括如何进行身份验证,请参阅 使用 GraphQL 发起调用。
您需要将所有 GraphQL 查询发送到迁移的目标。如果您迁移到具有数据驻留要求的 GitHub Enterprise Cloud,请确保将查询发送到您企业 GHE.com 子域的端点。
步骤 1:获取迁移目标的 ownerId
作为 GitHub Enterprise Cloud 中的组织所有者,请使用 GetOrgInfo 查询返回 ownerId(也称为组织 ID),即您希望拥有迁移后仓库的组织。您需要使用 ownerId 来确定迁移目标。
GetOrgInfo 查询
query(
$login: String!
){
organization (login: $login)
{
login
id
name
databaseId
}
}
| 查询变量 | 描述 |
|---|---|
login | 您的组织名称。 |
GetOrgInfo 响应
{
"data": {
"organization": {
"login": "Octo",
"id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
"name": "Octo-org",
"databaseId": 5610
}
}
}
在本例中,MDEyOk9yZ2FuaXphdGlvbjU2MTA= 是组织 ID 或 ownerId,我们将在下一步中使用它。
步骤 2:确定迁移来源
您可以使用 createMigrationSource 查询设置迁移来源。您需要提供从 GetOrgInfo 查询获得的 ownerId(组织 ID)。
您的迁移来源是 GitHub.com 上的一个组织。
createMigrationSource 变更
mutation createMigrationSource($name: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: "https://github.com", ownerId: $ownerId, type: GITHUB_ARCHIVE}) {
migrationSource {
id
name
url
type
}
}
}
注意
确保对 type 使用 GITHUB_ARCHIVE。
| 查询变量 | 描述 |
|---|---|
name | 迁移来源的名称。此名称仅供您参考,您可以使用任意字符串。 |
ownerId | 您在 GitHub Enterprise Cloud 上的组织 ID。 |
createMigrationSource 响应
{
"data": {
"createMigrationSource": {
"migrationSource": {
"id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
"name": "GitHub.com Source",
"url": "https://github.com",
"type": "GITHUB_SOURCE"
}
}
}
}
在本例中,MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA 是迁移来源 ID,我们将在下一步中使用它。
步骤 3:开始仓库迁移
当您启动迁移时,单个仓库及其相关数据将迁移到您指定的全新 GitHub 仓库中。
如果您想一次从同一来源组织迁移多个仓库,可以排队多个迁移。您最多可以同时运行 5 个仓库迁移。
startRepositoryMigration 变更
mutation startRepositoryMigration (
$sourceId: ID!,
$ownerId: ID!,
$sourceRepositoryUrl: URI!,
$repositoryName: String!,
$continueOnError: Boolean!,
$accessToken: String!,
$githubPat: String!,
$targetRepoVisibility: String!
){
startRepositoryMigration( input: {
sourceId: $sourceId,
ownerId: $ownerId,
repositoryName: $repositoryName,
continueOnError: $continueOnError,
accessToken: $accessToken,
githubPat: $githubPat,
targetRepoVisibility: $targetRepoVisibility
sourceRepositoryUrl: $sourceRepositoryUrl,
}) {
repositoryMigration {
id
migrationSource {
id
name
type
}
sourceUrl
}
}
}
| 查询变量 | 描述 |
|---|---|
sourceId | 您从 createMigrationSource 变更返回的迁移来源 id。 |
ownerId | 您在 GitHub Enterprise Cloud 上的组织 ID。 |
repositoryName | 一个自定义的唯一仓库名称,当前在 GitHub Enterprise Cloud 上的组织所拥有的仓库中未被使用。当迁移完成或停止时,将在此仓库中创建一个错误日志 issue。 |
continueOnError | 迁移设置,允许在遇到不会导致迁移失败的错误时继续迁移。必须为 true 或 false。我们强烈建议将 continueOnError 设置为 true,这样除非 Importer 无法移动 Git 源或失去连接且无法重新连接完成迁移,否则迁移将继续进行。 |
githubPat | 您在 GitHub Enterprise Cloud 上的目标组织的个人访问令牌。 |
accessToken | 您来源的个人访问令牌。 |
targetRepoVisibility | 新仓库的可见性。必须为 private、public 或 internal。如果未设置,仓库将以私有方式迁移。 |
sourceRepositoryUrl | 源仓库的 URL,使用格式 https://github.com/{organization}/{repository}。 |
有关个人访问令牌的要求,请参阅 管理 GitHub 产品之间迁移的访问权限。
在下一步中,您将使用 startRepositoryMigration 变更返回的迁移 ID 来检查迁移状态。
步骤 4:检查迁移状态
为了检测任何迁移失败并确保迁移正常工作,您可以使用 getMigration 查询检查迁移状态。您还可以使用 getMigrations 检查多个迁移的状态。
getMigration 查询将返回状态,告知迁移是 queued(已排队)、in progress(进行中)、failed(失败)还是 completed(已完成)。如果迁移失败,Importer 将提供失败原因。
getMigration 查询
query (
$id: ID!
){
node( id: $id ) {
... on Migration {
id
sourceUrl
migrationSource {
name
}
state
failureReason
}
}
}
| 查询变量 | 描述 |
|---|---|
id | 您迁移的 id,该 ID 由 startRepositoryMigration 变更返回。 |
步骤 5:验证迁移并检查错误日志
要完成迁移,我们建议您检查 “Migration Log” issue。该 issue 会在目标仓库的 GitHub 中创建。

最后,建议您检查已迁移的仓库,以确保其完整性。
步骤 1:安装 GitHub CLI 的 GEI 扩展
如果这是您第一次迁移,您需要安装 GitHub CLI 的 GEI 扩展。有关 GitHub CLI 的更多信息,请参阅 关于 GitHub CLI。
或者,您也可以从 发布页面 下载 github/gh-gei 仓库的独立二进制文件。下载后可直接运行该二进制文件,无需使用 gh 前缀。
-
安装 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 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:生成迁移脚本
如果您想一次性将多个仓库迁移到 GitHub Enterprise Cloud,请使用 GitHub CLI 生成迁移脚本。生成的脚本将包含每个仓库对应的迁移命令列表。
如果只迁移单个仓库,请直接跳到下一步。
生成迁移脚本
要生成迁移脚本,请运行 gh gei generate-script 命令。
gh gei generate-script --github-source-org SOURCE --github-target-org DESTINATION --output FILENAME
gh gei generate-script --github-source-org SOURCE --github-target-org DESTINATION --output FILENAME
如果您下载的是独立二进制文件而非 GitHub CLI 的扩展,则需要编辑生成的脚本,使其运行该二进制文件而不是 gh gei。
占位符
将上述命令中的占位符替换为以下值。
| 占位符 | 值 |
|---|---|
| SOURCE | 源组织的名称 |
| DESTINATION | 目标组织的名称 |
| FILENAME | 生成的迁移脚本文件名 如果您使用终端,请使用 .ps1 文件扩展名,因为生成的脚本需要 PowerShell 才能运行。您可以为 Mac 或 Linux 安装 PowerShell。 |
附加参数
| 参数 | 描述 |
|---|---|
--target-api-url TARGET-API-URL | 如果您迁移到 GHE.com,请添加 --target-api-url TARGET-API-URL,其中 TARGET-API-URL 是您企业子域的基础 API URL。例如:https://api.octocorp.ghe.com。 |
--download-migration-logs | 下载每个已迁移仓库的迁移日志。有关迁移日志的更多信息,请参阅 获取 GitHub Enterprise Importer 迁移日志。 |
审查迁移脚本
生成脚本后,请审查该文件,并可选择编辑脚本。
- 如果有不想迁移的仓库,请删除或注释掉相应的行。
- 如果您希望某些仓库在目标组织中使用不同的名称,请更新相应
--target-repo标志的值。 - 如果您想更改新仓库的可见性,请更新相应
--target-repo-visibility标志的值。默认情况下,脚本会将可见性设置为与源仓库相同。
如果您的仓库拥有超过 10 GB 的发行版数据,发行版将无法迁移。使用 --skip-releases 标志可在不迁移发行版的情况下迁移仓库。
如果您下载的是独立二进制文件而非 GitHub CLI 的扩展,则需要编辑生成的脚本,使其运行该二进制文件而不是 gh gei。
步骤 5:迁移仓库
您可以使用迁移脚本一次迁移多个仓库,也可以使用 gh gei migrate-repo 命令迁移单个仓库。
迁移多个仓库
要迁移多个仓库,请运行您生成的脚本。将以下命令中的 FILENAME 替换为生成脚本时指定的文件名。
-
如果您使用终端,请使用
./。Shell ./FILENAME
./FILENAME -
如果您使用 PowerShell,请使用
.\。Shell .\FILENAME
.\FILENAME
迁移单个仓库
要迁移单个仓库,请使用 gh gei migrate-repo 命令。
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME
gh gei migrate-repo --github-source-org SOURCE --source-repo CURRENT-NAME --github-target-org DESTINATION --target-repo NEW-NAME
占位符
将上述命令中的占位符替换为以下值。
| 占位符 | 值 |
|---|---|
| SOURCE | 源组织的名称 |
| CURRENT-NAME | 要迁移的仓库名称 |
| DESTINATION | 目标组织的名称 |
| NEW-NAME | 迁移后仓库的新名称 |
附加参数
| 参数 | 描述 |
|---|---|
--target-api-url TARGET-API-URL | 如果您迁移到 GHE.com,请添加 --target-api-url TARGET-API-URL,其中 TARGET-API-URL 是您企业子域的基础 API URL。例如:https://api.octocorp.ghe.com。 |
--skip-releases | 如果您的仓库拥有超过 10 GB 的发行版数据,发行版将无法迁移。使用 --skip-releases 标志可在不迁移发行版的情况下迁移仓库。 |
--target-repo-visibility TARGET-VISIBILITY | 仓库默认以私有可见性迁移。若要设置可见性,可添加 --target-repo-visibility 标志,并指定 private、public 或 internal。如果迁移目标是拥有托管用户的企业,公共仓库不可用。 |
中止迁移
如果想取消迁移,请使用 abort-migration 命令,并将 MIGRATION-ID 替换为 migrate-repo 返回的 ID。
gh gei abort-migration --migration-id MIGRATION-ID
gh gei abort-migration --migration-id MIGRATION-ID
步骤 6:验证迁移并检查错误日志
迁移完成后,我们建议您查看迁移日志。更多信息请参阅 访问 GitHub Enterprise Importer 迁移日志。
我们建议您对已迁移的仓库进行完整性检查。