{"meta":{"title":"使用企业实时迁移迁移存储库","intro":"在停机时间最短的情况下，从GitHub Enterprise Server迁移到GHE.com。","product":"迁移","breadcrumbs":[{"href":"/zh/enterprise-server@3.18/migrations","title":"迁移"},{"href":"/zh/enterprise-server@3.18/migrations/elm","title":"实时迁移（GHES 到 GHE.com）"},{"href":"/zh/enterprise-server@3.18/migrations/elm/migrate-your-repository","title":"迁移存储库"}],"documentType":"article"},"body":"# 使用企业实时迁移迁移存储库\n\n在停机时间最短的情况下，从GitHub Enterprise Server迁移到GHE.com。\n\n> \\[!TIP] 按照本指南操作，可以参考 [企业实时迁移 命令行界面参考](/zh/enterprise-server@3.18/migrations/elm/elm-cli-reference) 获取更详细的用法信息。 如果遇到错误，请参阅 [排查从 GitHub Enterprise Server 到 GHE.com 的实时迁移问题](/zh/enterprise-server@3.18/migrations/elm/troubleshooting)。\n\n## 先决条件\n\n确保环境和开发人员已准备好进行迁移。 请参阅“[准备从 GitHub Enterprise Server 到 GHE.com 的实时迁移](/zh/enterprise-server@3.18/migrations/elm/prepare-for-your-migration)”。\n\n## 1. 配置 GitHub Enterprise Server\n\n在创建令牌和执行迁移之前， GitHub Enterprise Server 必须在实例上设置一些配置。 这些配置值适用于所有 ELM 迁移。\nGitHub Enterprise Server应用新配置时，开发人员可能会遇到短暂的停机时间。\n\n1. GitHub Enterprise Server通过 SSH 访问管理程序。 请参阅“[访问管理 shell (SSH)](/zh/enterprise-server@3.18/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh)”。\n2. 使用 `ghe-config`. 设置以下配置变量。\n\n   例如：`ghe-config app.elm-exporter.enabled true`\n\n   | 可变                                                   | 将此设置为...                                            |\n   | ---------------------------------------------------- | --------------------------------------------------- |\n   | `app.elm-exporter.enabled`                           | `true`                                              |\n   | `app.elm.internal-webhooks-enabled`                  | `true`                                              |\n   | `app.elm-exporter.webhooks-loopback-address-enabled` | `true`                                              |\n   | `secrets.elm-exporter.migration-target-url`          | 目标企业的 API URL（例如： `https://api.octocorp.ghe.com`） 。 |\n\n**不要**在 URL 的末尾包含尾部斜杠。 |\n\\| `secrets.elm-exporter.source-user` | 与操作员令牌 GitHub Enterprise Server 关联的用户名。 这应该是你在 GitHub Enterprise Server 上的用户名；如果其他人要创建此令牌，则此处的值应设置为他们的用户名。 我们推荐`ghe-admin`用户。 |\n\n1. 应用配置。\n\n   ```shell copy\n   ghe-config-apply\n   ```\n\n2. 退出 SSH 会话。 在本地终端会话中运行其余命令。\n\n## 2.创建具有企业访问权限的操作员令牌\n\n操作员必须使用向源企业和目标企业进行身份验证。 有关创建令牌的说明，请参阅 [管理个人访问令牌](/zh/enterprise-server@3.18/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic)。\n\n**确保记下这两个令牌**，因为下一步将需要它们。\n\n1. 在 **GitHub Enterprise Server** 上，创建 personal access token (classic) 并选择所需的范围：\n\n   * `admin:enterprise`\n\n   配置时，将此令牌用作**源令牌**ELM CLI。\n\n2. 在 **GHE.com** 上，创建一个 personal access token (classic) 并选择所需的作用域：\n\n   * `admin:enterprise`\n   * `admin:org`\n\n   配置时，将此令牌用作**目标令牌**ELM CLI。\n\n## 3.配置 ELM 命令行工具\n\n你将从本地终端会话中运行迁移，并使用 GitHub CLI 的扩展程序。\n\n1. 在本地计算机上安装[GitHub CLI](https://cli.github.com/)。 必须使用版本 2.0 或更高版本。\n\n2. 安装 ELM 扩展。\n\n   ```shell copy\n   gh extension install github/gh-elm\n   ```\n\n3. 启动安装向导以配置扩展。\n\n   ```shell copy\n   gh elm configure\n   ```\n\n4. 按照安装向导中的说明操作，为源端和目标端提供 API URL（例如：`https://api.SUBDOMAIN.ghe.com`），以及您在上一步中创建的令牌。\n\n这些值中的任何值也可以作为 CLI 标志提供给任何 `gh elm` 命令，这将优先于配置。 例如： `--target-url https://api.SUBDOMAIN.ghe.com`。\n\n此设置过程会将 URL 存储到操作系统配置目录中一个特定于平台的配置文件里，位置为 `gh-elm/config.json`。 访问令牌将安全地存储在计算机的机密存储中。\n\n## 4.配置实时迁移机密\n\n除了具有企业访问权限的操作员令牌外，还必须为源组织和目标组织创建一个 personal access token (classic) 令牌。 对于要从中迁移的每个组织，必须重复这些步骤。\n\n### 创建访问令牌\n\nELM 必须使用 personal access token (classic) 对迁移的源和目标进行身份验证。 有关创建令牌的说明，请参阅 [管理个人访问令牌](/zh/enterprise-server@3.18/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic)。\n\n**请务必记下这些令牌**，因为在下一步中会用到它们。\n\n1. 在**GitHub Enterprise Server** 上创建一个personal access token (classic)，并使用以下作用域：\n\n   * `repo`\n   * `admin:org`\n   * `admin:repo_hook`\n   * `admin:org_hook`\n\n   这是你的源令牌。\n\n2. 在 **GHE.com** 上创建一个具有以下范围的 personal access token (classic)：\n\n   * `repo`\n   * `workflow`\n   * `admin:org`\n   * `admin:repo_hook`\n   * `admin:enterprise`\n\n   这是你的目标令牌。\n\n   > \\[!IMPORTANT]\n   > 如果在 GHE.com 上对目标组织强制实施了单点登录，则必须为单点登录授权 GHE.com 令牌。\n\n### 配置组织的 ELM 机密信息\n\n使用 `gh elm config` 命令设置源和目标访问令牌：\n\n1. 设置源令牌。\n\n   ```shell copy\n   gh elm config set-source-pat EXISTING-GHES-ORG\n   ```\n\n   当系统询问时，将源令牌粘贴到终端。\n\n2. 设置目标令牌。\n\n   ```shell copy\n   gh elm config set-target-pat EXISTING-GHES-ORG\n   ```\n\n   当系统询问时，将目标令牌粘贴到终端。\n\n您还可以通过 `gh elm config org-tokens EXISTING-GHES-ORG` 以交互方式设置令牌，或者在位于 `https://GHES_HOSTNAME/organizations/EXISTING-GHES-ORG/settings/secrets/elm-exporter/` 的组织设置中进行设置。\n\n## 5. 创建迁移\n\n通过指定源和目标存储库详细信息创建新的迁移。\n\n> \\[!NOTE]\n> `target-org`可以是新的或现有的。 如果目标组织尚不存在，则会在迁移期间创建它。 但是，不会迁移来自源组织的设置。\n\n```shell copy\ngh elm migration create \\\n  --source-org EXISTING-GHES-ORG \\\n  --source-repo EXISTING-GHES-REPO \\\n  --target-org GHEC-ORG \\\n  --target-repo NEW-GHEC-REPO\n```\n\n例如：\n\n```shell\ngh elm migration create \\\n  --source-org my-ghes-org \\\n  --source-repo my-ghes-repo \\\n  --target-org my-dr-org \\\n  --target-repo my-dr-repo\n```\n\n可选标志：\n\n* `--start`：如果已准备好立即开始迁移。\n* `--target-visibility`：默认情况下，迁移的存储库是使用 **内部** 可见性创建的，但可以指定 `private`。\n\n### 保存迁移 ID\n\n应会看到如下所示的响应：\n\n```json\n{\n  \"migrationId\": \"2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9\",\n  \"expiresAt\": \"2026-02-11T21:49:33.619162159Z\"\n}\n```\n\n导出 `migrationId` 为变量，因为下一个命令将需要它。 例如：\n\n```shell\nexport MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'\n```\n\n## 6. 开始迁移\n\n如果尚未启动迁移，请使用刚刚保存的迁移 ID 立即启动它。\n\n```shell copy\ngh elm migration start --migration-id $MIGRATION_ID\n```\n\n这会启动回填和实时更新过程。\nELM 正在从源存储库收集数据，并且监听支持的 Webhook 事件。\n\n## 7. 监视迁移\n\n迁移开始时，应会看到新的存储库。GHE.com 在迁移过程中，你将看到存储库填充了初始数据负载，并在开发人员继续在源存储库中工作时接收更新。\n\n可以使用以下命令以交互方式 `watch` 监视迁移进度：\n\n```shell\ngh elm migration watch $MIGRATION_ID\n```\n\n这将轮询迁移状态 API，并显示一个可自动刷新的文本界面，以反映当前进度。\n\n### 使用 `migration status` 进行程序化监控\n\n如果您需要适用于自动化的迁移状态信息，请使用 `status` 命令：\n\n```shell copy\ngh elm migration status --migration-id $MIGRATION_ID\n```\n\n响应中最重要的指示器是 **combinedState** 对象中的状态。 当状态达到 `COMBINED_STATUS_READY_FOR_CUTOVER`时，应准备好继续执行下一步。 但是，如果任何单个资源未能成功迁移，您可能需要对此进行调查，届时`displayMessage`中会发出警报。\n\n例如：\n\n```json\n  \"combinedState\":  {\n    \"status\":  \"COMBINED_STATUS_READY_FOR_CUTOVER\",\n    \"displayMessage\":  \"Ready for cutover (1 resources failed)\",\n    \"repositories\":  [\n      {\n        \"repositoryNwo\":  \"new-test-org/my-new-repo\",\n        \"phase\":  \"REPOSITORY_PHASE_READY_FOR_CUTOVER\",\n        \"displayStatus\":  \"Ready for cutover (1 failed)\"\n      }\n    ],\n    \"readyForCutover\":  true,\n    \"cutoverBlockers\":  []\n  },\n```\n\n提示：\n\n* 如果运行的是多个迁移，则可以检查 `gh elm migration list`所有这些迁移的状态。 此命令默认显示正在进行的迁移，但也可以按此 `--status`进行筛选。\n* 如果遇到需要注意的失败状态，请参阅 [排查从 GitHub Enterprise Server 到 GHE.com 的实时迁移问题](/zh/enterprise-server@3.18/migrations/elm/troubleshooting#statuses-and-recommended-actions)。\n\n## 8. 完成迁移\n\n当迁移准备好进行切换时，可以完成迁移。 切换过程将存档源存储库，使其**永久处于只读状态**，除非存储库管理员将其解除存档。\n\n```shell copy\ngh elm migration cutover --migration-id $MIGRATION_ID\n```\n\n继续监视迁移。 在响应顶部看到 `MIGRATION_STATUS_COMPLETED` 状态时，迁移已完成，但仍有一些后续任务需要执行，以便为 GitHub Enterprise Server 的用户提供访问权限。\n\n## 后续步骤\n\n向用户授予对新存储库的访问权限，并将活动与用户帐户进行协调。 请参阅“[完成从 GitHub Enterprise Server 到 GHE.com 的实时迁移](/zh/enterprise-server@3.18/migrations/elm/complete-your-migration)”。"}