注意
还可以用 ADO2GH extension of the GitHub CLI 来执行迁移。 请参阅“阶段 1。 了解从 Azure DevOps 迁移到 GitHub”。
步骤 0:准备好使用 GitHub GraphQL API
要进行 GraphQL 查询,需要编写自己的脚本或使用 HTTP 客户端(如 Insomnia)。
若要详细了解 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:确定要从何处迁移
迁移源是 ADO 组织。
`createMigrationSource` 突变
mutation createMigrationSource($name: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
migrationSource {
id
name
url
type
}
}
}
注意
请确保对 type 使用 AZURE_DEVOPS。
| 查询变量 | 说明 |
|---|---|
name | 迁移源的名称。 此名称仅供你自己参考,因此可以使用任何字符串。 |
ownerId | GitHub Enterprise Cloud 上组织的组织 ID。 |
`createMigrationSource` 响应
{
"data": {
"createMigrationSource": {
"migrationSource": {
"id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
"name": "Azure DevOps Source",
"url": "https://dev.azure.com",
"type": "AZURE_DEVOPS"
}
}
}
}
在此示例中,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 上拥有的任何存储库当前未使用的自定义唯一存储库名称。 迁移完成或停止时,将在此存储库中创建一个错误记录问题。 |
continueOnError | 迁移设置,允许在遇到不会导致迁移失败的错误时继续迁移。 必须为 true 或 false。 强烈建议将 continueOnError 设置为 true,以便继续迁移,除非 Importer 无法移动 Git 源,或 Importer 已断开连接且无法重新连接以完成迁移。 |
githubPat | 目标组织在 GitHub Enterprise Cloud 上的 personal access token。 |
accessToken | 源的 personal access token。 |
targetRepoVisibility | 新存储库的可见性。 必须为 private、public 或 internal。 如果未设置,则存储库将作为专用存储库迁移。 |
sourceRepositoryUrl | 源存储库的 URL,格式为 https://dev.azure.com/{organization}/{project}/_git/{repository}。 |
有关 personal access token 要求的信息,请参阅 阶段 2。 管理访问权限。
在下一步中,将使用从 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 | startRepositoryMigration 突变返回的迁移的 id。 |
步骤 5:验证迁移并检查错误日志
要完成迁移,建议检查“迁移日志”问题。 此问题在目标存储库中的 GitHub 上创建。

最后,建议查看已迁移的存储库以进行完整性检查。
延伸阅读
-
[AUTOTITLE](/migrations/ado/phase-6-follow-up-tasks) -
[AUTOTITLE](/migrations/ado/key-differences-between-azure-devops-and-github)