跳至主要内容

将仓库从 GitHub.com 迁移到 GitHub Enterprise Cloud

您可以使用 GitHub CLI 或 GraphQL API 将仓库从 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 产品之间迁移的访问权限

步骤 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迁移设置,允许在遇到不会导致迁移失败的错误时继续迁移。必须为 truefalse。我们强烈建议将 continueOnError 设置为 true,这样除非 Importer 无法移动 Git 源或失去连接且无法重新连接完成迁移,否则迁移将继续进行。
githubPat您在 GitHub Enterprise Cloud 上的目标组织的个人访问令牌。
accessToken您来源的个人访问令牌。
targetRepoVisibility新仓库的可见性。必须为 privatepublicinternal。如果未设置,仓库将以私有方式迁移。
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 中创建。

Screenshot of an issue with the title "Migration Log." The second comment in the issue includes logs for a migration.

最后,建议您检查已迁移的仓库,以确保其完整性。

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

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

或者,您也可以从 发布页面 下载 github/gh-gei 仓库的独立二进制文件。下载后可直接运行该二进制文件,无需使用 gh 前缀。

  1. 安装 GitHub CLI。有关 GitHub CLI 的安装说明,请参阅 GitHub CLI 仓库

    注意

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

  2. 安装 GEI 扩展。

    Shell
    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 之前,您必须创建能够访问源组织和目标组织的个人访问令牌,然后将这些令牌设置为环境变量。

  1. 创建并记录一个(经典)个人访问令牌,用于对 GitHub Enterprise Cloud 上的目标组织进行身份验证,确保该令牌满足所有要求。有关详细信息,请参阅 管理 GitHub 产品之间迁移的访问权限

  2. 创建并记录一个个人访问令牌,用于对源组织进行身份验证,同样确保该令牌满足所有相同要求。

  3. 为个人访问令牌设置环境变量,在下面的命令中将 TOKEN 替换为您上面记录的令牌。对目标组织使用 GH_PAT,对源组织使用 GH_SOURCE_PAT

    • 如果您使用 Terminal,请使用 export 命令。

      Shell
      export GH_PAT="TOKEN"
      export GH_SOURCE_PAT="TOKEN"
      
    • 如果您使用 PowerShell,请使用 $env 命令。

      Shell
      $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

    • 如果您使用 Terminal,请使用 export 命令。

      Shell
      export TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
      
    • 如果您使用 PowerShell,请使用 $env 命令。

      Shell
      $env:TARGET_API_URL="https://api.SUBDOMAIN.ghe.com"
      

    您将在使用 GitHub CLI 运行的命令中,通过 --target-api-url 选项使用此变量。

步骤 4:生成迁移脚本

如果您想一次性将多个仓库迁移到 GitHub Enterprise Cloud,请使用 GitHub CLI 生成迁移脚本。生成的脚本将包含每个仓库对应的迁移命令列表。

注意

生成脚本会输出一个 PowerShell 脚本。如果您使用终端,需要将脚本保存为 .ps1 扩展名,并为 MacLinux 安装 PowerShell 才能运行它。

如果只迁移单个仓库,请直接跳到下一步。

生成迁移脚本

要生成迁移脚本,请运行 gh gei generate-script 命令。

Shell
gh gei generate-script --github-source-org SOURCE --github-target-org DESTINATION --output FILENAME

如果您下载的是独立二进制文件而非 GitHub CLI 的扩展,则需要编辑生成的脚本,使其运行该二进制文件而不是 gh gei

占位符

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

占位符
SOURCE源组织的名称
DESTINATION目标组织的名称
FILENAME生成的迁移脚本文件名

如果您使用终端,请使用 .ps1 文件扩展名,因为生成的脚本需要 PowerShell 才能运行。您可以为 MacLinux 安装 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
    
  • 如果您使用 PowerShell,请使用 .\

    Shell
    .\FILENAME
    

迁移单个仓库

要迁移单个仓库,请使用 gh gei migrate-repo 命令。

Shell
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 标志,并指定 privatepublicinternal。如果迁移目标是拥有托管用户的企业,公共仓库不可用。

中止迁移

如果想取消迁移,请使用 abort-migration 命令,并将 MIGRATION-ID 替换为 migrate-repo 返回的 ID。

Shell
gh gei abort-migration --migration-id MIGRATION-ID

步骤 6:验证迁移并检查错误日志

迁移完成后,我们建议您查看迁移日志。更多信息请参阅 访问 GitHub Enterprise Importer 迁移日志

我们建议您对已迁移的仓库进行完整性检查。

© . This site is unofficial and not affiliated with GitHub, Inc.