Проверка состояния миграции
Сначала проверьте успешность или сбой миграции.
Способ проверки состояния миграции зависит от способа запуска миграции.
-
Если вы запускали миграцию по GitHub CLIумолчанию с , процесс покажет, удалось ли или не прошло миграцию после завершения. Если миграция завершилась сбоем, вы увидите причину сбоя.
Migration completed (ID: RM_123)! State: SUCCEEDED -
Если вы запускали миграцию с GitHub CLI аргументом с опциональным
--queue-only, процесс сразу же завершится после очереди на миграцию и не укажет, прошла ли миграция успешно или неудачно. Вы можете проверить состояние миграции с помощьюwait-for-migrationкоманды или просмотреть журнал миграции.
Просмотр журнала миграции
Вам следует ознакомиться с журналом миграции для каждого мигрированного репозитория. Пользователи с доступом к репозиторию могут получить доступ к журналу миграции репозитория на GitHub.
-
Перейдите в перенесенный репозиторий в целевой организации.
-
В поле имени репозитория щелкните Issues.

-
Щелкните проблему с заголовком "Журнал миграции".
Дополнительные сведения см. в разделе Доступ к журналам миграции для GitHub Enterprise Importer.
Настройка видимости репозитория
Все репозитории переносятся как частные по умолчанию, и доступ к репозиторию будет иметь только пользователь, выполняющий миграцию и владелец организации. Если вы не хотите, чтобы репозиторий был частным, измените видимость.
-
Вы можете изменить видимость репозитория в браузере. Дополнительные сведения см. в разделе Настройка видимости репозитория.
-
В качестве альтернативы можно GitHub CLI изменить видимость репозитория из командной строки. Для получения дополнительной информации см.
gh repo editв GitHub CLI документации.Например, замените YOUR_ORG на название вашей организации, и команда ниже установит внутреннюю видимость всех репозиториев организации.
Bash export ORG=YOUR_ORG gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internalexport ORG=YOUR_ORG gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internal
Восстановление манекенов
После выполнения миграции с помощью GitHub Enterprise Importerвсе действия пользователя в перенесенном репозитории (за исключением фиксаций Git) относятся к удостоверениям заполнителей, называемым манекенами.
Примечание.
Только владелец организации могут восстановить манекины. Если вы предоставили роль миграции, обратитесь к владелец организации, чтобы выполнить этот шаг.
- Решите, хотите ли вы восстановить манекины.
- Запланируйте, когда вы завершите восстановление.
- Восстановление манекенов. Дополнительные сведения см. в разделе Восстановление манекенов для GitHub Enterprise Importer.
- Если любой из членов еще не имеет соответствующего доступа к репозиторию через членство в команде, предоставьте членам доступ к репозиторию. Дополнительные сведения см. в разделе Управление доступом пользователя к репозиторию организации.
Настройка списков разрешений IP-адресов
Если вы добавили диапазоны IP-адресов в GitHub Enterprise Importer список разрешений IP-адресов вашей организации-получателя, вы сможете удалить эти записи. Если вы отключили ограничения списка разрешений поставщика удостоверений для целевого предприятия, их можно повторно включить.
Configure Azure Pipelines and Azure Boards
Если вы раньше пользовались Azure Pipelines или Azure Boards и хотите продолжать использовать их с репозиториями, теперь, когда они размещены на GitHub, вы можете следовать этим руководствам на Майкрософт Learn, чтобы настроить соответствующее расширение.
-
[Соединить Azure Pipelines с GitHub](https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/github) -
[Настройте приложение Azure Boards для GitHub](https://learn.microsoft.com/en-us/azure/devops/boards/github/install-github-app)
Поддержка ваших разработчиков в их новой среде
Есть некоторые различия между Azure DevOps и GitHub, которые было бы полезно знать вам и вашим разработчикам. Поделитесь с ними автозаголовком .