{"meta":{"title":"Principais diferenças entre Azure DevOps e GitHub","intro":"Os principais fluxos de trabalho, como acesso ao repositório, autenticação e solicitações de pull, diferem depois de passar de Azure DevOps para GitHub.","product":"Migrações","breadcrumbs":[{"href":"/pt/enterprise-cloud@latest/migrations","title":"Migrações"},{"href":"/pt/enterprise-cloud@latest/migrations/ado","title":"Migrar de Azure DevOps"},{"href":"/pt/enterprise-cloud@latest/migrations/ado/key-differences-between-azure-devops-and-github","title":"Principais diferenças"}],"documentType":"article"},"body":"# Principais diferenças entre Azure DevOps e GitHub\n\nOs principais fluxos de trabalho, como acesso ao repositório, autenticação e solicitações de pull, diferem depois de passar de Azure DevOps para GitHub.\n\nSe você for membro de uma organização que migrou de Azure DevOps para GitHub, este guia explicará as alterações em seus fluxos de trabalho para tornar a migração o mais suave possível.\n\n## Estrutura\n\nEm Azure DevOps, os repositórios são aninhados dentro de projetos **team**, portanto, a estrutura do seu ambiente tem esta aparência:\n\n* Organização\n  * Projeto da equipe\n    * Repositórios\n  * Projeto da equipe\n    * Repositórios\n\nAs permissões e a visibilidade são definidas a partir do projeto da equipe.\n\nGitHub é estruturado de forma diferente. Os repositórios estão aninhados diretamente dentro das **organizações**, que também contêm equipes:\n\n* Conta empresarial\n  * Organização\n    * Equipes\n    * Repositórios\n  * Organização\n    * Equipes\n    * Repositórios\n\nAs permissões e a visibilidade são determinadas por uma combinação de associação da organização, associação à equipe e permissões individuais.\n\nO conceito de um projeto de equipe, que é usado para agrupar repositórios em Azure DevOps, não existe em GitHub e tratar organizações em GitHub como o equivalente de projetos de equipe não é recomendado.\n\nEmbora você possa inicialmente encontrar cada organização GitHub migrada com uma longa lista de repositórios desorganizada, você pode conceder acesso e permissões por meio de equipes de membros da organização, o que facilita muito a navegação nos repositórios da organização.\n\n## Autenticação, permissões e equipes\n\nHá dois métodos de autenticação no GitHub. Qual método você usar dependerá de como a conta corporativa está configurada.\n\nSe sua conta corporativa usar Enterprise Managed Users, você entrará no GitHub por meio do provedor de identidade (por exemplo, Entra ID) e usará uma conta **provisionada** vinculada à conta corporativa.\n\nCaso contrário, você usará uma conta **pessoal**GitHub . Essa conta será convidada para a conta corporativa e para todas as organizações nas quais você trabalhar. Se a conta corporativa estiver configurada com restrições de acesso SAML adicionais, sua conta pessoal será **vinculada** ao IdP. Você será solicitado a autenticar com o IdP quando precisar acessar recursos na conta corporativa.\n\nEm uma empresa no GitHub, os repositórios podem ser públicos, privados ou internos. Repositórios privados só são visíveis para pessoas e equipes com acesso explícito, e repositórios internos são visíveis para todos os membros da sua empresa, mas não para pessoas de fora da empresa. Repositórios internos são úteis quando várias organizações na mesma empresa precisam descobrir e reutilizar código. Se sua empresa usar Enterprise Managed Users, as contas de usuário não poderão criar repositórios públicos ou outro conteúdo público.\n\n## Usar o Git\n\nPara continuar trabalhando em seus repositórios usando o Git, você precisará fazer algumas alterações.\n\n1. Atualize URLs remotas para apontar para GitHub. Confira [Gerenciar repositórios remote](/pt/enterprise-cloud@latest/get-started/git-basics/managing-remote-repositories).\n2. Atualize como você se autentica.\n   * Para usar a autenticação HTTPS, você precisará criar uma personal access token. Confira [Gerenciar seus tokens de acesso pessoal](/pt/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n   * Para usar a autenticação SSH, você precisará criar ou adicionar uma chave SSH existente.GitHub Confira [Conectando-se ao GitHub com o SSH](/pt/enterprise-cloud@latest/authentication/connecting-to-github-with-ssh).\n3. Se sua empresa ou organização usar o SSO (Single Sign-On) do SAML, você deverá autorizar sua personal access token chave SSH antes que ela possa acessar recursos.\n\n## Fluxo de solicitações de pull\n\nCom a base de código agora hospedada GitHub, você proporá alterações usando solicitações de pull criadas em seus GitHub repositórios.\n\nSe sua empresa integrou o Azure Boards e os Pipelines, ambos funcionarão com GitHub. Você pode continuar a referenciar itens de trabalho em suas mensagens de confirmação e solicitações de pull. Por exemplo: `Fix login bug (AB#1234)`.\n\nVocê pode continuar exibindo e gerenciando seus itens de trabalho no Azure Boards. Você também pode vincular branches, confirmações e pull requests a itens de trabalho dentro do Azure. Consulte [Link GitHub confirmações, solicitações de pull, branches e problemas para itens de trabalho no Azure Boards](https://learn.microsoft.com/en-us/azure/devops/boards/github/link-to-from-github) no Microsoft Learn.\n\n## Proteções de ramificação\n\nPessoas com acesso administrativo a um repositório podem configurar regras de **proteção de branch** em GitHub. Eles são semelhantes às políticas de **branch** no Azure DevOps e definem regras, como um número mínimo de revisores aprovadores, checagens de status bem-sucedidas e a exigência de commits assinados.\n\nGitHub também dá suporte à atribuição automática de revisores com base nos padrões de arquivo, pasta e padrões globais no arquivo CODEOWNERS de um repositório. Confira [Sobre os proprietários de código](/pt/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).\n\n## Pacotes e artefatos\n\nEm Azure DevOps, você pode ter usado Azure Artifacts para publicar e consumir pacotes (por exemplo, pacotes NuGet, pacotes npm ou pacotes Maven) e armazenar artefatos de build produzidos por Azure Pipelines.\n\nEm GitHub, os pacotes normalmente são publicados no GitHub Packages e associados a um repositório ou organização. Dependendo de como sua empresa concluiu a migração, você pode continuar publicando pacotes para Azure Artifacts, mover pacotes para GitHub Packages ou usar uma combinação de ambos.\n\nSe você não conseguir mais restaurar dependências após a migração, verifique a configuração de origem do pacote. Por exemplo, talvez seja necessário atualizar uma URL do Registro ou credenciais em arquivos como `nuget.config`, `.npmrc`ou `settings.xml`em sua configuração de pipeline.\n\nPara saber mais, confira [Introdução ao GitHub Packages](/pt/enterprise-cloud@latest/packages/learn-github-packages/introduction-to-github-packages).\n\n## GitHub Copilot\n\nHospedar seus repositórios em GitHub desbloqueia todo o poder de Copilot. Sua base de código fornece Copilot todo o contexto de que precisa para responder perguntas em Copilot Chat, examinar e fazer sugestões em seus pull requests e até mesmo fazer alterações em seu lugar com Copilot cloud agent.\n\nConfira [Início Rápido para GitHub Copilot](/pt/enterprise-cloud@latest/copilot/get-started/quickstart)."}