Skip to main content

Этап 1. Understand migrations from Azure DevOps to GitHub

GitHub Enterprise Importer can automate migrating from Azure DevOps.

О миграциях из Azure DevOps Cloud

Вы можете использовать GitHub Enterprise Importer для переноса репозиториев из Azure DevOps в GitHub Enterprise Cloud (GitHub.com или GHE.com).

Вы можете использовать только GitHub Enterprise Importer для миграции из Azure DevOps Cloud, а не из Azure DevOps Server. Если вы используете Azure DevOps Server и хотите перейти на GitHub, сначала можно перейти в Azure DevOps Cloud. Дополнительные сведения см. в статье "Миграция в Azure DevOps " на сайте Azure.

Прежде чем создавать корпоративный аккаунт на GitHub, решите, будет ли ваша компания использовать Enterprise Managed Users. Это влияет на то, как ваши участники проходят аутентификацию и как вы управляете идентификацией и доступом. См . раздел AUTOTITLE.

Поддержка Azure Pipelines и Azure Boards

И Azure Pipelines, и Azure Boards могут быть полностью интегрированы с вашим опытом GitHub. Вы можете настроить корпоративную учетную запись и Azure DevOps, чтобы продолжать пользоваться этими сервисами, при этом получая выгоду от размещения репозиториев на GitHub.

Если вы хотите перенести Azure Pipelines на GitHub Actions, обратитесь к руководителю учетных записей GitHub.

Данные, перенесенные

GitHub Enterprise Importer в настоящее время поддерживает миграцию следующих данных репозитория из Azure DevOps в GitHub Enterprise Cloud.

  • Источник Git (включая журнал фиксаций)
  • Запросы на слияние
  • Журнал пользователей для запросов на вытягивание
  • Ссылки рабочих элементов на запросы на вытягивание
  • Вложения при запросах на вытягивание
  • Политики ветви для репозитория (политики филиалов с областью действия пользователя и политики межрепличной ветви не включены)

Ограничения для перенесенных данных

Существуют ограничения на то, что GitHub Enterprise Importer может перенести. Некоторые из-за ограничений GitHub, а другие являются ограничениями GitHub Enterprise Importer.

Ограничения GitHub

  •         **Ограничение размера 2 ГиБ для одного коммита Git:** Размер отдельного коммита в репозитории Git не должен превышать 2 ГиБ. Если размер любого из ваших коммитов превышает 2 ГиБ, вам нужно будет разделить коммит на более мелкие коммиты, каждый из которых имеет размер 2 ГиБ или меньше.
    
  •         **Ограничение в 255 байт для ссылок на Git:** Ни одна ссылка на Git, обычно называемая «ref», не может иметь имя больше 255 байт. Обычно это означает, что ваши ссылки не могут превышать 255 символов, но любые не-ASCII символы, такие как эмодзи, могут потреблять более одного байта. Если какая-либо из ссылок на Git слишком велика, мы вернем четкое сообщение об ошибке.
    
  •         **Ограничение на размер файла 100 МиБ:** После завершения миграции размер отдельного файла в репозитории Git не должен превышать 100 МиБ. Во время миграции репозитория этот лимит увеличивается до 400 МиБ. Рекомендуется использовать Git LFS для хранения больших файлов.
    

Ограничения GitHub Enterprise Importer

  • Ограничение размера 40 ГБ для репозитория Git (public preview): это ограничение применяется только к исходному коду. Чтобы проверить, превышает ли архив репозитория ограничение, используйте средство git-sizer и просмотрите общий размер большого двоичного объекта в выходных данных. Средство git-sizer также помогает определить потенциальные проблемы, связанные с большими файлами, размером больших двоичных объектов, размером фиксации и числом деревьев, которые могут повлиять на миграцию.
  •         **Ограничение размера файла 400 MiB:** при переносе репозитория с GitHub Enterprise Importer, в репозитории Git не может быть больше 400 МиБ. Рекомендуется использовать Git LFS для хранения больших файлов.
    
  •         **Объекты  не перенесены:** Importer может перенести репозитории, использующие Git LFS, но сами объекты LFS не будут перенесены. Их можно отправить в место назначения миграции в качестве последующей задачи после завершения миграции.
    
  •         **Функции поиска отложенного кода:** повторное индексирование индекса поиска может занять несколько часов после переноса репозитория, а поиски кода могут возвращать непредвиденные результаты до завершения повторной индексации.
    
  •         **Наборы правил, настроенные для вашей организации, могут привести к сбою миграции:** например, если вы настроили правило, требующее адреса электронной почты для автор фиксации `@monalisa.cat`заканчиваться, а репозиторий, с которым вы переносите, содержит фиксации, которые не соответствуют этому правилу, миграция завершится ошибкой.
    
  •         **Содержимое манекена может быть недоступен для поиска:** Манекены являются заполнителями пользователей, к которым связан импортированный контент (например, проблемы, запросы на вытягивание, комментарии и т. д.). При поиске содержимого, связанного с манекеном, например назначенными проблемами, проблемы могут быть не найдены. После восстановления манекена содержимое должно быть найдено с помощью нового владельца.
    

Дальнейшие шаги

В следующей статье вы решите, кто будет осуществлять миграцию, и подготовите доступ как к Azure DevOps, так и к GitHub Enterprise Cloud. См . раздел AUTOTITLE.