Ключевые отличия между Azure DevOps и GitHub

Основные рабочие процессы, такие как доступ к репозиторию, аутентификация и pull requests, меняются после перехода с Azure DevOps на GitHub.

В этой статье

Если вы являетесь членом организации, которая перешла с Azure DevOps на GitHub, это руководство объяснит изменения в ваших рабочих процессах, чтобы сделать миграцию максимально гладкой.

Структура

В Azure DevOps репозитории встроены в проекты team projects, поэтому структура вашей среды выглядит так:

  • Организация
    • Командный проект
      • Репозитории
    • Командный проект
      • Репозитории

Права и видимость появляются от командного проекта.

          GitHub структурирована иначе. Репозитории встроены непосредственно внутри **организаций**, которые также включают команды:
  • Корпоративная учетная запись
    • Организация
      • Команды
      • Репозитории
    • Организация
      • Команды
      • Репозитории

Права и видимость определяются сочетанием членства в организации, команды и индивидуальных прав.

Концепция командного проекта, которая используется для группирования репозиториев в Azure DevOps, не существует в GitHub, и рассматривать организации в GitHub как эквивалент командных проектов не рекомендуется.

Хотя изначально у каждой мигрированной организации GitHub может быть длинный и неорганизованный список репозиториев, доступ и разрешения можно предоставлять через команды членов организации, что значительно облегчает навигацию по репозиториям организации.

Аутентификация, права и команды

Существует два способа аутентификации по GitHub. Выбор метода будет зависеть от того, как настроен корпоративный аккаунт.

Если ваш корпоративный аккаунт использует Enterprise Managed Users, вы войдёте в GitHub через провайдера идентификации (например, Entra ID) и используете аккаунт provisioned, привязанный к корпоративному аккаунту.

В противном случае вы будете использовать личныйGitHub аккаунт. Этот аккаунт будет приглашён в корпоративный аккаунт и все организации, в которых вы будете работать. Если корпоративный аккаунт настроен с дополнительными ограничениями доступа к SAML, ваш личный аккаунт будет привязан к вашему IDP. Вам попросят пройти аутентификацию с помощью IDP, когда вам нужно получить доступ к ресурсам корпоративной учетной записи.

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

С помощью Git

Чтобы продолжать работать над репозиториями на Git, вам нужно внести некоторые изменения.

  1. Обновите удалённые URL-адреса на GitHub. См . раздел AUTOTITLE.
  2. Обновите способ аутентификации.
    • Чтобы использовать HTTPS-аутентификацию, вам нужно создать personal access token. См . раздел AUTOTITLE.
    • Чтобы использовать SSH-аутентификацию, вам нужно либо создать, либо добавить существующий SSH-ключ в GitHub. См . раздел AUTOTITLE.
  3. Если ваше предприятие или организация использует SAML single sign-on (SSO), вы должны авторизовать свой personal access token или SSH-ключ, прежде чем он сможет получить доступ к ресурсам.

Поток pull request

Теперь, когда ваша кодовая база размещена GitHub, вы будете предлагать изменения с помощью pull request, созданных в ваших GitHub репозиториях.

Если в вашем предприятии интегрированы Azure Boards и конвейеры, они оба будут работать с GitHub. Вы можете продолжать ссылаться на рабочие элементы в коммит-сообщениях и pull requests. Например: Fix login bug (AB#1234).

Вы можете продолжать просматривать и управлять рабочими элементами на Azure Boards. Вы также можете связывать ветки, коммиты и pull requests с рабочими элементами из Azure. См. Link GitHub коммиты, пулл-запросы, ветки и проблемы с рабочими элементами в Azure Boards на Майкрософт Learn.

Защита ветвей

Люди с администраторским доступом к репозиторию могут настраивать правила защиты веток на GitHub. Они похожи на политики branch policy на Azure DevOps и устанавливают правила, такие как минимальное количество одобряющих рецензентов, успешные проверки статуса и требование подписанных коммитов.

          GitHub также поддерживает автоматическое назначение рецензентов на основе шаблонов файла, папки и глоба в файле CODEOWNERS репозитория. См [. раздел AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).

Посылки и артефакты

В Azure DevOps вы, возможно, использовали Azure Artifacts для публикации и потребления пакетов (например, пакетов NuGet, npm пакетов или пакетов Maven) и для хранения артефактов сборки, созданных Azure Pipelines.

На GitHub, пакеты обычно публикуются и GitHub Packages связаны с репозиторием или организацией. В зависимости от того, как ваше предприятие завершило миграцию, вы можете продолжать публиковать пакеты в Azure Artifacts, перемещать пакеты на GitHub Packages или использовать комбинацию обоих вариантов.

Если после миграции вы больше не можете восстановить зависимости, проверьте конфигурацию исходного кода пакета. Например, вам может понадобиться обновить URL реестра или учетные данные в файлах вроде nuget.config, .npmrc, settings.xml, или в конфигурации вашего конвейера.

Дополнительные сведения см. в разделе Введение в GitHub Packages.

GitHub Copilot

Размещение репозиториев на GitHub разблокирует полную мощность Copilot. Ваша кодовая база предоставляет Copilot весь необходимый контекст для ответов на вопросы Copilot Chat, просмотра и внесения предложений в pull requests, а также для внесения изменений от вашего имени с Copilot облачный агентпомощью .

См . раздел AUTOTITLE.