将数据迁移到 GitHub Enterprise Server

准备迁移的数据

使用 scp 命令，将从源实例或组织生成的迁移归档复制到目标 GitHub Enterprise Server。
```
scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
```
通过 SSH 登录到目标 GitHub Enterprise Server 实例。更多信息，请参阅访问管理 Shell（SSH）。
```
ssh -p 122 admin@HOSTNAME
```
确保迁移归档具有足够的读取权限。
```
chmod 644 /home/admin/MIGRATION-GUID.tar.gz
```
使用 ghe-migrator prepare 命令为目标实例上的导入准备归档，并生成一个新的 Migration GUID，以便在后续步骤中使用。
```
ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
```
- 要开始新的导入尝试，请再次运行 ghe-migrator prepare 并获取新的 Migration GUID。
- 若要指定迁移文件的暂存位置，请在命令后添加 --staging-path=/full/staging/path。默认路径为 /data/user/tmp。

生成迁移冲突列表

使用带有 Migration GUID 的 ghe-migrator conflicts 命令，生成一个 conflicts.csv 文件。
```
ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
```
- 如果未报告冲突，您可以安全地导入数据。
如果存在冲突，请使用 scp 命令将 conflicts.csv 复制到本地计算机。
```
scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
```
继续至解决迁移冲突或设置自定义映射。

审查迁移冲突

使用文本编辑器或 CSV 兼容的电子表格软件打开 conflicts.csv。
根据以下示例和参考表，审查 conflicts.csv 文件，确保在导入时采取正确的操作。

conflicts.csv 文件包含冲突的迁移映射及推荐操作。迁移映射列出了从源迁移的数据信息以及这些数据将在目标端如何应用。

`模型名称`	`源 URL`	`目标 URL`	`推荐操作`
`user`	`https://example-gh.source/octocat`	`https://example-gh.target/octocat`	`映射`
`organization`	`https://example-gh.source/octo-org`	`https://example-gh.target/octo-org`	`映射`
`repository`	`https://example-gh.source/octo-org/widgets`	`https://example-gh.target/octo-org/widgets`	`重命名`
`团队`	`https://example-gh.source/orgs/octo-org/teams/admins`	`https://example-gh.target/orgs/octo-org/teams/admins`	`合并`

conflicts.csv 中的每一行提供以下信息

名称	描述
`模型名称`	要更改的数据类型。
`源 URL`	数据的源 URL。
`目标 URL`	数据的预期目标 URL。
`推荐操作`	ghe-migrator 在导入数据时将采取的首选操作。

每种记录类型的可能映射

ghe-migrator 在传输数据时可以采取多种不同的映射操作

`action`	描述	适用模型
`导入`	(默认) 将源数据导入到目标。	所有记录类型
`映射`	不是基于源数据创建新模型，而是使用目标中已有的记录。此方式适用于将仓库导入已有组织，或将目标中的用户身份映射到源中的用户身份。	用户、组织
`重命名`	先对源数据重命名，然后复制到目标。	用户、组织、仓库
`映射或重命名`	如果目标已存在，则映射到该目标；否则，对导入的模型进行重命名。	用户
`合并`	将源数据与目标上已有的数据合并。	Teams

我们强烈建议您审查 conflicts.csv 文件并使用 ghe-migrator audit 确认已采取正确的操作。 如果一切正常，您可以继续。

解决迁移冲突或设置自定义映射

如果您认为 ghe-migrator 将执行错误的更改，您可以通过修改 conflicts.csv 中的数据来纠正。您可以更改 conflicts.csv 中的任意行。

例如，假设您注意到源端的 octocat 用户被映射到目标端的 octocat。

`模型名称`	`源 URL`	`目标 URL`	`推荐操作`
`user`	`https://example-gh.source/octocat`	`https://example-gh.target/octocat`	`映射`

您可以选择将该用户映射到目标端的其他用户。假设您知道 octocat 在目标端实际上应该是 monalisa。您可以将 conflicts.csv 中的 target_url 列改为指向 monalisa。

`模型名称`	`源 URL`	`目标 URL`	`推荐操作`
`user`	`https://example-gh.source/octocat`	`https://example-gh.target/monalisa`	`映射`

再举一个例子，如果您想将目标实例上的 octo-org/widgets 仓库重命名为 octo-org/amazing-widgets，请将 target_url 改为 octo-org/amazing-widgets，并将 recommend_action 改为 rename。

`模型名称`	`源 URL`	`目标 URL`	`推荐操作`
`repository`	`https://example-gh.source/octo-org/widgets`	`https://example-gh.target/octo-org/amazing-widgets`	`重命名`

添加自定义映射

在迁移过程中，一个常见的情况是迁移的用户在目标端的用户名与源端不同。

给定源端的用户名列表和目标端的用户名列表，您可以创建一个包含自定义映射的 CSV 文件并应用它，以确保在迁移结束时每个用户的用户名和内容被正确归属。

您可以使用 ghe-migrator audit 命令快速生成符合自定义映射需求的用户迁移 CSV。

ghe-migrator audit -m user -g MIGRATION-GUID > users.csv

现在，您可以编辑该 CSV，为每个希望映射或重命名的用户输入新的 URL，然后在第四列填入相应的 map 或 rename。

例如，要将目标 https://example-gh.target 上的用户 octocat 重命名为 monalisa，您需要在行中填写如下内容

`模型名称`	`源 URL`	`目标 URL`	`状态`
`user`	`https://example-gh.source/octocat`	`https://example-gh.target/monalisa`	`重命名`

相同的过程可用于为每种支持自定义映射的记录创建映射。更多信息请参阅我们的记录可能映射表。

应用修改后的迁移数据

修改完成后，使用 scp 命令将您修改后的 conflicts.csv（或任何其他符合格式的映射 .csv 文件）应用到目标实例。
```
scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
```
使用 ghe-migrator map 命令重新映射迁移数据，传入修改后 .csv 文件的路径以及 Migration GUID。
```
ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
```
如果 ghe-migrator map -i conflicts.csv -g MIGRATION-GUID 命令仍报告存在冲突，请再次执行迁移冲突解决过程。

在 GitHub Enterprise Server 上应用导入的数据

通过 SSH 登录到目标 GitHub Enterprise Server 实例。更多信息，请参阅访问管理 Shell（SSH）。
```
ssh -p 122 admin@HOSTNAME
```
使用 ghe-migrator import 命令启动导入过程。您需要
- 您的迁移 GUID。更多信息请参见为导入到 GitHub Enterprise Server 准备迁移数据。
- 用于身份验证的个人访问令牌。您使用的个人访问令牌仅用于作为站点管理员进行身份验证，不需要任何特定的作用域或权限。更多信息请参见管理个人访问令牌。
```
$ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN

> Starting GitHub::Migrator
> Import 100% complete /
```
- 若要指定迁移文件的暂存位置，请在命令后添加 --staging-path=/full/staging/path。默认路径为 /data/user/tmp。

审查迁移数据

默认情况下，ghe-migrator audit 会返回所有记录。它还允许您按以下方式过滤记录：

记录的类型。
记录的状态。

记录类型与迁移数据中的类型相匹配。

记录类型过滤器

记录类型	过滤器名称
用户	`user`
组织	`organization`
仓库	`repository`
Teams	`团队`
里程碑	`里程碑`
议题	`议题`
议题评论	`issue_comment`
拉取请求	`拉取请求`
拉取请求审查	`拉取请求审查`
提交评论	`提交评论`
拉取请求审查评论	`pull_request_review_comment`
发布	`发布`
对拉取请求或议题采取的操作	`issue_event`
受保护分支	`protected_branch`

记录状态过滤器

记录状态	描述
`导出`	该记录将被导出。
`导入`	该记录将被导入。
`映射`	该记录将被映射。
`重命名`	该记录将被重命名。
`合并`	该记录将被合并。
`已导出`	该记录已成功导出。
`已导入`	该记录已成功导入。
`已映射`	该记录已成功映射。
`已重命名`	该记录已成功重命名。
`已合并`	该记录已成功合并。
`导出失败`	该记录导出失败。
`导入失败`	该记录导入失败。
`映射失败`	该记录映射失败。
`重命名失败`	该记录重命名失败。
`合并失败`	该记录合并失败。

过滤已审计记录

使用 ghe-migrator audit 命令，您可以使用 -m 标志按记录类型过滤；同样，使用 -s 标志可按导入状态过滤。命令如下所示：

ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID

例如，要查看所有成功导入的组织和团队，您可以输入：

$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed

我们强烈建议审计每一次导入失败的情况。 若要执行此操作，您需要输入：

$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed

如果您对导入失败有任何疑虑，可访问 GitHub Enterprise Support 与我们联系。

在 GitHub Enterprise Server 上完成导入

在将迁移应用到目标实例并审查完迁移后，您将解锁仓库并在源端删除它们。在删除源数据之前，建议等待约两周，以确保一切按预期运行。

解锁目标实例上的仓库

通过 SSH 登录到 GitHub.com。如果您的实例由多个节点组成，例如配置了高可用性或地理复制，请 SSH 登录到主节点。如果您使用集群，可登录任意节点。将 HOSTNAME 替换为您的实例主机名，或节点的主机名或 IP 地址。更多信息请参阅访问管理 Shell（SSH）。
Shell
```
ssh -p 122 admin@HOSTNAME
```
```
ssh -p 122 admin@HOSTNAME
```
使用 ghe-migrator unlock 命令解锁所有已导入的仓库。您需要提供迁移 GUID。

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project

警告

如果您的仓库包含使用 schedule 触发器的 GitHub Actions 工作流，导入后这些工作流不会自动运行。要重新启动计划的工作流，请向仓库推送一次提交。更多信息请参阅触发工作流的事件。

解锁源端的仓库

在迁移完成后，您应该解锁源端的仓库。

解锁 GitHub.com 组织上的仓库

要解锁 GitHub.com 组织上的仓库，您需要向迁移解锁端点发送 DELETE 请求。您需要：

用于身份验证的访问令牌
迁移的唯一 id
要解锁的仓库名称

curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock

从 GitHub.com 组织中删除仓库

在解锁 GitHub.com 组织的仓库后，您应该使用仓库删除端点删除所有先前迁移的仓库。您需要用于身份验证的访问令牌。

curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  https://api.github.com/repos/ORG-NAME/REPO_NAME

从 GitHub Enterprise Server 实例中解锁仓库

通过 SSH 登录到 GitHub.com。如果您的实例由多个节点组成，例如配置了高可用性或地理复制，请 SSH 登录到主节点。如果您使用集群，可登录任意节点。将 HOSTNAME 替换为您的实例主机名，或节点的主机名或 IP 地址。更多信息请参阅访问管理 Shell（SSH）。
Shell
```
ssh -p 122 admin@HOSTNAME
```
```
ssh -p 122 admin@HOSTNAME
```
使用 ghe-migrator unlock 命令解锁所有已导入的仓库。您需要提供迁移 GUID。

$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project

本文内容