{"meta":{"title":"Diferencias clave entre Azure DevOps y GitHub","intro":"Los flujos de trabajo principales, como el acceso al repositorio, la autenticación y las solicitudes de incorporación de cambios, difieren después de pasar de Azure DevOps a GitHub.","product":"Migraciones","breadcrumbs":[{"href":"/es/enterprise-cloud@latest/migrations","title":"Migraciones"},{"href":"/es/enterprise-cloud@latest/migrations/ado","title":"Migración desde Azure DevOps"},{"href":"/es/enterprise-cloud@latest/migrations/ado/key-differences-between-azure-devops-and-github","title":"Diferencias clave"}],"documentType":"article"},"body":"# Diferencias clave entre Azure DevOps y GitHub\n\nLos flujos de trabajo principales, como el acceso al repositorio, la autenticación y las solicitudes de incorporación de cambios, difieren después de pasar de Azure DevOps a GitHub.\n\nSi es miembro de una organización que ha migrado de Azure DevOps a GitHub, esta guía explicará los cambios en los flujos de trabajo para que la migración sea lo más fluida posible.\n\n## Estructura\n\nEn Azure DevOps, los repositorios se anidan dentro de proyectos **team**, por lo que la estructura del entorno tiene este aspecto:\n\n* Organización\n  * Proyecto de equipo\n    * Repositorios\n  * Proyecto de equipo\n    * Repositorios\n\nLos permisos y la visibilidad fluyen desde el proyecto del equipo.\n\nGitHub está estructurado de forma diferente. Los repositorios se anidan directamente dentro de **las organizaciones**, que también contienen equipos:\n\n* Cuenta de empresa\n  * Organización\n    * Equipos\n    * Repositorios\n  * Organización\n    * Equipos\n    * Repositorios\n\nLos permisos y la visibilidad se determinan mediante una combinación de pertenencia a la organización, pertenencia al equipo y permisos individuales.\n\nEl concepto de un proyecto de equipo, que se usa para agrupar repositorios en Azure DevOps, no existe en GitHub. Tratar a las organizaciones en GitHub como equivalente de proyectos de equipo no es recomendable.\n\nAunque puede que inicialmente encuentre que cada organización migrada en GitHub tiene una larga lista no organizada de repositorios, puede conceder acceso y permisos a través de equipos de miembros de la organización, lo que facilita enormemente la navegación por sus repositorios.\n\n## Autenticación, permisos y equipos\n\nHay dos métodos para autenticarse en GitHub. El método que use dependerá de cómo se configure la cuenta de empresa.\n\nSi la cuenta empresarial usa Enterprise Managed Users, iniciarás sesión en GitHub a través del proveedor de identidades (por ejemplo, Entra ID) y utilizarás una cuenta **provisionada** asociada a la cuenta empresarial.\n\nDe lo contrario, usarás una cuenta **personal**GitHub. Esa cuenta será invitada a unirse a la cuenta de empresa y a todas las organizaciones en las que participe. Si la cuenta empresarial está configurada con restricciones de acceso de SAML adicionales, su cuenta personal se **vinculará** a su IdP. Se le pedirá que se autentique con el IdP cuando necesite acceder a los recursos dentro de la cuenta de empresa.\n\nEn una empresa en GitHub, los repositorios pueden ser públicos, privados o internos. Los repositorios privados solo son visibles para personas y equipos con acceso explícito, y los repositorios internos son visibles para todos los miembros de su empresa, pero no para personas ajenas a la empresa. Los repositorios internos son útiles cuando varias organizaciones de la misma empresa necesitan detectar y reutilizar código. Si su empresa usa Enterprise Managed Users, las cuentas de usuario no pueden crear repositorios públicos u otro contenido público.\n\n## Utilizar GitHub\n\nPara seguir trabajando en los repositorios mediante Git, deberá realizar algunos cambios.\n\n1. Actualice las direcciones URL remotas para que apunten a GitHub. Consulta [Administrar repositorios remotos](/es/enterprise-cloud@latest/get-started/git-basics/managing-remote-repositories).\n2. Actualice cómo se autentica.\n   * Para usar la autenticación HTTPS, deberá crear un personal access token. Consulta [Administración de tokens de acceso personal](/es/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).\n   * Para usar la autenticación SSH, deberá crear o agregar una clave SSH existente a GitHub. Consulta [Conexión a GitHub con SSH](/es/enterprise-cloud@latest/authentication/connecting-to-github-with-ssh).\n3. Si su empresa u organización usa SAML de inicio de sesión único (SSO), debe autorizar su personal access token o clave SSH antes de que pueda obtener acceso a los recursos.\n\n## Flujo de solicitud de incorporación de cambios\n\nCon el código base ahora hospedado en GitHub, propondrá cambios mediante solicitudes de incorporación de cambios creadas en los repositorios de GitHub.\n\nSi tu empresa ha integrado Azure Boards y Pipelines, ambas funcionarán con GitHub. Puede seguir haciendo referencia a elementos de trabajo en los mensajes de confirmación y las solicitudes de incorporación de cambios. Por ejemplo: `Fix login bug (AB#1234)`.\n\nPuede seguir viendo y administrando los elementos de trabajo en Azure Boards. También puede vincular ramas, confirmaciones y solicitudes de incorporación de cambios a elementos de trabajo desde Azure. Consulte [Vinculación de confirmaciones, solicitudes de incorporación de cambios, ramas e incidencias de GitHub a elementos de trabajo en Azure Boards](https://learn.microsoft.com/en-us/azure/devops/boards/github/link-to-from-github) en Microsoft Learn.\n\n## Protecciones de rama\n\nLos usuarios con acceso de administrador a un repositorio pueden configurar **reglas de protección de rama** en GitHub. Son similares a las directivas de **branch** en Azure DevOps y establecen reglas como un número mínimo de revisores que aprueben, comprobaciones de estado exitosas y la necesidad de confirmaciones firmadas.\n\nGitHub también admite la asignación automática de revisores en función de los patrones file, folder y glob en el archivo CODEOWNERS de un repositorio. Consulta [Acerca de los propietarios de código](/es/enterprise-cloud@latest/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners).\n\n## Paquetes y artefactos\n\nEn Azure DevOps, es posible que haya usado Azure Artifacts para publicar y consumir paquetes (por ejemplo, paquetes NuGet, paquetes npm o paquetes maven) y para almacenar artefactos de compilación generados por Azure Pipelines.\n\nEn GitHub, los paquetes normalmente se publican en GitHub Packages y se asocian a un repositorio o organización. En función de cómo la empresa haya completado la migración, puede seguir publicando paquetes en Azure Artifacts, mover paquetes a GitHub Packages o usar una combinación de ambos.\n\nSi ya no puede restaurar las dependencias después de la migración, compruebe la configuración del origen del paquete. Por ejemplo, puede que tenga que actualizar una dirección URL del Registro o credenciales en archivos como `nuget.config`, `.npmrc`, `settings.xml`o en la configuración de la canalización.\n\nPara más información, consulta [Introducción a los paquetes de GitHub](/es/enterprise-cloud@latest/packages/learn-github-packages/introduction-to-github-packages).\n\n## GitHub Copilot\n\nHospedar los repositorios en GitHub desbloquea toda la potencia de Copilot. El código base proporciona a Copilot todo el contexto que necesita para responder a preguntas en Copilot Chat, revisar y realizar sugerencias en las solicitudes de incorporación de cambios e incluso realizar cambios en su lugar con Copilot cloud agent.\n\nConsulta [Inicio rápido para GitHub Copilot](/es/enterprise-cloud@latest/copilot/get-started/quickstart)."}