{"meta":{"title":"Ключевые отличия между Azure DevOps и GitHub","intro":"Основные рабочие процессы, такие как доступ к репозиторию, аутентификация и pull requests, меняются после перехода с Azure DevOps на GitHub.","product":"Миграции","breadcrumbs":[{"href":"/ru/enterprise-cloud@latest/migrations","title":"Миграции"},{"href":"/ru/enterprise-cloud@latest/migrations/ado","title":"Migrate from Azure DevOps"},{"href":"/ru/enterprise-cloud@latest/migrations/ado/key-differences-between-azure-devops-and-github","title":"Основные отличия"}],"documentType":"article"},"body":"# Ключевые отличия между Azure DevOps и GitHub\n\nОсновные рабочие процессы, такие как доступ к репозиторию, аутентификация и pull requests, меняются после перехода с Azure DevOps на GitHub.\n\nЕсли вы являетесь членом организации, которая перешла с Azure DevOps на GitHub, это руководство объяснит изменения в ваших рабочих процессах, чтобы сделать миграцию максимально гладкой.\n\n## Структура\n\nВ Azure DevOps репозитории встроены в проекты **team projects**, поэтому структура вашей среды выглядит так:\n\n* Организация\n  * Командный проект\n    * Репозитории\n  * Командный проект\n    * Репозитории\n\nПрава и видимость появляются от командного проекта.\n\nGitHub структурирована иначе. Репозитории встроены непосредственно внутри **организаций**, которые также включают команды:\n\n* Корпоративная учетная запись\n  * Организация\n    * Команды\n    * Репозитории\n  * Организация\n    * Команды\n    * Репозитории\n\nПрава и видимость определяются сочетанием членства в организации, команды и индивидуальных прав.\n\nКонцепция командного проекта, которая используется для группирования репозиториев в Azure DevOps, не существует в GitHub, и рассматривать организации в GitHub как эквивалент командных проектов не рекомендуется.\n\nХотя изначально у каждой мигрированной организации GitHub может быть длинный и неорганизованный список репозиториев, доступ и разрешения можно предоставлять через команды членов организации, что значительно облегчает навигацию по репозиториям организации.\n\n## Аутентификация, права и команды\n\nСуществует два способа аутентификации по GitHub. Выбор метода будет зависеть от того, как настроен корпоративный аккаунт.\n\nЕсли ваш корпоративный аккаунт использует Enterprise Managed Users, вы войдёте в GitHub через провайдера идентификации (например, Entra ID) и используете аккаунт **provisioned**, привязанный к корпоративному аккаунту.\n\nВ противном случае вы будете использовать **личный**GitHub аккаунт. Этот аккаунт будет приглашён в корпоративный аккаунт и все организации, в которых вы будете работать. Если корпоративный аккаунт настроен с дополнительными ограничениями доступа к SAML, ваш личный аккаунт будет **привязан** к вашему IDP. Вам попросят пройти аутентификацию с помощью IDP, когда вам нужно получить доступ к ресурсам корпоративной учетной записи.\n\nВ компании GitHubна рынке репозитории могут быть публичными, частными или внутренними. Приватные репозитории видны только людям и командам с явным доступом, а внутренние репозитории видны всем участникам вашего предприятия, но не для тех, кто вне предприятия. Внутренние репозитории полезны, когда нескольким организациям в одном предприятии необходимо найти и повторно использовать код. Если ваше предприятие использует Enterprise Managed Users, не могут создавать публичные репозитории или другой публичный контент.\n\n## С помощью Git\n\nЧтобы продолжать работать над репозиториями на Git, вам нужно внести некоторые изменения.\n\n1. Обновите удалённые URL-адреса на GitHub. См [. раздел AUTOTITLE](/ru/enterprise-cloud@latest/get-started/git-basics/managing-remote-repositories).\n2. Обновите способ аутентификации.\n   * Чтобы использовать HTTPS-аутентификацию, вам нужно создать personal access token. См [. раздел AUTOTITLE](/ru/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n   * Чтобы использовать SSH-аутентификацию, вам нужно либо создать, либо добавить существующий SSH-ключ в GitHub. См [. раздел AUTOTITLE](/ru/enterprise-cloud@latest/authentication/connecting-to-github-with-ssh).\n3. Если ваше предприятие или организация использует SAML single sign-on (SSO), вы должны авторизовать свой personal access token или SSH-ключ, прежде чем он сможет получить доступ к ресурсам.\n\n## Поток pull request\n\nТеперь, когда ваша кодовая база размещена GitHub, вы будете предлагать изменения с помощью pull request, созданных в ваших GitHub репозиториях.\n\nЕсли в вашем предприятии интегрированы Azure Boards и конвейеры, они оба будут работать с GitHub. Вы можете продолжать ссылаться на рабочие элементы в коммит-сообщениях и pull requests. Например: `Fix login bug (AB#1234)`.\n\nВы можете продолжать просматривать и управлять рабочими элементами на Azure Boards. Вы также можете связывать ветки, коммиты и pull requests с рабочими элементами из Azure. См. [Link GitHub коммиты, пулл-запросы, ветки и проблемы с рабочими элементами в Azure Boards](https://learn.microsoft.com/en-us/azure/devops/boards/github/link-to-from-github) на Майкрософт Learn.\n\n## Защита ветвей\n\nЛюди с администраторским доступом к репозиторию могут настраивать **правила защиты веток** на GitHub. Они похожи на политики **branch policy** на Azure DevOps и устанавливают правила, такие как минимальное количество одобряющих рецензентов, успешные проверки статуса и требование подписанных коммитов.\n\nGitHub также поддерживает автоматическое назначение рецензентов на основе шаблонов файла, папки и глоба в файле CODEOWNERS репозитория. См [. раздел AUTOTITLE](/ru/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).\n\n## Посылки и артефакты\n\nВ Azure DevOps вы, возможно, использовали Azure Artifacts для публикации и потребления пакетов (например, пакетов NuGet, npm пакетов или пакетов Maven) и для хранения артефактов сборки, созданных Azure Pipelines.\n\nНа GitHub, пакеты обычно публикуются и GitHub Packages связаны с репозиторием или организацией. В зависимости от того, как ваше предприятие завершило миграцию, вы можете продолжать публиковать пакеты в Azure Artifacts, перемещать пакеты на GitHub Packages или использовать комбинацию обоих вариантов.\n\nЕсли после миграции вы больше не можете восстановить зависимости, проверьте конфигурацию исходного кода пакета. Например, вам может понадобиться обновить URL реестра или учетные данные в файлах вроде `nuget.config`, `.npmrc`, `settings.xml`, или в конфигурации вашего конвейера.\n\nДополнительные сведения см. в разделе [Введение в GitHub Packages](/ru/enterprise-cloud@latest/packages/learn-github-packages/introduction-to-github-packages).\n\n## GitHub Copilot\n\nРазмещение репозиториев на GitHub разблокирует полную мощность Copilot. Ваша кодовая база предоставляет Copilot весь необходимый контекст для ответов на вопросы Copilot Chat, просмотра и внесения предложений в pull requests, а также для внесения изменений от вашего имени с Copilot cloud agentпомощью .\n\nСм [. раздел AUTOTITLE](/ru/enterprise-cloud@latest/copilot/get-started/quickstart)."}