Acerca de las migraciones entre productos de GitHub

Acerca de las migraciones entre productos de GitHub

Con GitHub Enterprise Importer, puedes migrar datos de GitHub Enterprise Server a GitHub Enterprise Cloud, o bien migrar datos de GitHub.com a otra cuenta de GitHub Enterprise Cloud.

Por ejemplo, GitHub Enterprise Importer puede ayudar a tu empresa a:

• Adoptar Nube de GitHub Enterprise con residencia de datos mediante la migración de la empresa a GHE.com
• Adoptar determinadas características en GitHub.com, como Enterprise Managed Users o nuevos modelos de facturación, mediante la migración entre empresas en GitHub.com
• Beneficiarse de la administración simplificada y las nuevas características mediante la migración de GitHub Enterprise Server a GitHub Enterprise Cloud

Si el origen de la migración es una cuenta en GitHub.com, puedes migrar repositorios individuales entre organizaciones o migrar organizaciones enteras entre empresas. Si el origen de la migración es GitHub Enterprise Server, puedes migrar repositorios individuales.

Los datos que GitHub Enterprise Importer migra dependen del origen de la migración y de si está migrando un repositorio o una organización.

Consideraciones sobre las migraciones a GitHub Enterprise Cloud

Antes de usar GitHub Enterprise Importer, ten en cuenta las consideraciones siguientes:

• Si ya usas GitHub Enterprise Cloud: un plan de GitHub Enterprise te da derecho a una implementación de GitHub Enterprise Cloud.

  Por ejemplo, si ya usas GitHub.com, y también quieres migrar de GitHub Enterprise Server a GHE.com, tu uso de ambos no lo cubrirá ningún plan.

• Si vas a migrar a Enterprise Managed Users: deberás integrarte con un proveedor de identidades para administrar cuentas de usuario. Comprueba el nivel de compatibilidad con el proveedor de identidades antes de empezar. Consulta Acerca de Enterprise Managed Users.

• Si vas a migrar de GitHub Enterprise Server: ten en cuenta que GitHub aplica límites de volumen a determinadas acciones, que están deshabilitadas de forma predeterminada en GitHub Enterprise Server. Consulta Límites de volumen de la API de REST.

• Si vas a migrar a Nube de GitHub Enterprise con residencia de datos: ten en cuenta que algunas características no están disponibles y otras requieren una configuración adicional o diferente. Consulta Introducción a las características de la nube de GitHub Enterprise con residencia de datos.

Datos que se migran de GitHub Enterprise Server

Para realizar la migración desde GitHub Enterprise Server (GHES), debes tener la versión 3.4.1 o superior de GHES. Los datos que se migran dependen de la versión que utilice.

Elemento	GHES 3.4.1+	GHES 3.5.0+
Origen de Git (incluido el historial de confirmaciones)
Solicitudes de incorporación de cambios
Issues
Hitos
Wikis
Flujos de trabajo de GitHub Actions
Comentarios sobre confirmación de cambios
Webhooks (deben volver a habilitarse después de la migración. Consulta Habilitación de webhooks).
Protecciones de rama
Configuración de GitHub Pages
Historial de usuarios de los datos anteriores
Elementos adjuntos (consulta Adjuntar archivos)
Versiones

Se aplican distintos límites de tamaño por repositorio en función de la versión de GHES.

Límite	GHES <3.8.0	GHES 3.8.0+
Origen de Git	2 GB	10 GB
Metadatos	2 GB	10 GB

Datos que no se migran

Actualmente, no se migran los datos siguientes.

• Registros de auditoría
• Code scanning results
• Confirmación de las comprobaciones de estado
• Alertas de Dependabot
• Secretos de Dependabot
• Debates en el nivel de repositorio
• Editar historial de comentarios sobre incidencias y solicitudes de incorporación de cambios
• Relaciones de bifurcación entre repositorios (consulta Acerca de las bifurcaciones)
• GitHub Actions secretos, variables, ambientes, ejecutores autohospedados, ejecutor más grandes o historial de ejecución de flujo de trabajo
• GitHub Apps e instalaciones de aplicaciones de GitHub
• Los objetos de Git LFS y los archivos binarios grandes (los repositorios que usan Git LFS siguen siendo compatibles, consulta Limitaciones de GitHub Enterprise Importer)
• Vínculos de confirmaciones a solicitudes de cambios fusionadas mediante cambio de base
• Paquetes en GitHub Packages
• Projects (la nueva experiencia de proyectos)
• Referencias entre las solicitudes de cambios y las incidencias en los distintos repositorios (consulta Referencias y direcciones URL autovinculadas)
• Estados de corrección de los resultados de secret scanning
• Repositorios propiedad de cuentas de usuario
• Fuente de actividad del repositorio
• Propiedades del repositorio
• Estrellas del repositorio
• Observadores del repositorio
• Conjuntos de reglas
• Reglas de protección de etiquetas
• Perfiles de los usuarios, claves SSH, claves de firma o personal access tokens
• Secretos de webhook
• Teams
• Acceso de usuario o equipo al repositorio
• Configuración del repositorio para solicitudes de incorporación de cambios

Protecciones de rama

Las protecciones de rama aplican un conjunto especificado de reglas a un nombre de rama concreto o patrón de nombre de rama. Para más información, consulta Acerca de las ramas protegidas.

Las protecciones de rama siempre se migrarán, pero algunas reglas no. Las siguientes reglas de protección de rama no se migran.

• Permitir que actores específicos omitan las solicitudes de incorporación de cambios necesarias
• Exigir aprobación de la inserción más reciente
• Implementaciones correctas obligatorias antes de la combinación
• Bloqueo de una rama
• Restricción de inserciones que crean ramas coincidentes
• Permitir las subidas forzadas

También se aplican las siguientes limitaciones:

• Si una regla de protección de rama permite especificar opcionalmente personas, equipos o aplicaciones que están exentas de la regla, como "Restringir quién puede descartar las revisiones de solicitudes de incorporación de cambios", las excepciones no se migrarán.
• Si la regla "Permitir inserciones forzadas" está habilitada en el modo "Especificar quién puede forzar la inserción", la regla no se migrará.

Datos que se migran de GitHub.com

Si el origen de la migración es una cuenta en GitHub.com, puedes migrar repositorios individuales entre organizaciones o migrar organizaciones enteras entre empresas.

Datos migrados para una organización

Al migrar una organización, se crea una dentro de la cuenta empresarial de destino. Después, se migran los datos siguientes a la nueva organización.

• Teams
• Repositorios
• Acceso de equipo a los repositorios
• Privilegios de miembro
• Webhooks de nivel de organización (deben volver a habilitarse después de la migración; consulta Habilitación de webhooks)
• Nombre de rama predeterminado para los repositorios creados en la organización

Todos los repositorios se migran con visibilidad privada. Si quieres establecer la visibilidad de un repositorio en público o interno, puedes hacerlo después de la migración mediante la interfaz de usuario o la API.

No se migra la pertenencia a equipos. Después de la migración, tendrás que agregar miembros a los equipos migrados. Para más información, consulta Introducción a una migración entre productos de GitHub.

Datos migrados para un repositorio

Al migrar un repositorio, ya sea directamente o como parte de una migración de la organización, solo se migran los datos siguientes.

• Origen de Git (incluido el historial de confirmaciones)
• Solicitudes de incorporación de cambios
• Issues
• Hitos
• Wikis (excluye elementos adjuntos)
• Flujos de trabajo de GitHub Actions
• Comentarios sobre confirmación de cambios
• Webhooks activos (deben volver a habilitarse después de la migración; consulta Habilitación de webhooks)
• Temas del repositorio
• Configuración del repositorio
  • Protecciones de rama (consulta Protecciones de rama para más información)
  • Configuración de GitHub Pages
  • Referencias de vínculos automáticos
  • Configuración de solicitudes de incorporación de cambios
    • Eliminar automáticamente ramas principales
    • Permitir combinación automática
    • Permitir confirmaciones de combinación (la configuración del mensaje de confirmación se restablece al mensaje predeterminado)
    • Permitir fusión mediante combinación con "squash" (la configuración del mensaje de confirmación se restablece al mensaje predeterminado)
    • Permitir fusión mediante cambio de base
• Versiones (hasta 10 GB por repositorio)
• Historial de usuarios de los datos anteriores
• Elementos adjuntos (consulta Adjuntar archivos)

Datos que no se migran

Actualmente, no se migran los datos siguientes.

• Codespaces secretos * Registros de auditoría
• Code scanning results
• Confirmación de las comprobaciones de estado
• Alertas de Dependabot
• Secretos de Dependabot
• Debates en el nivel de repositorio
• Editar historial de comentarios sobre incidencias y solicitudes de incorporación de cambios
• Relaciones de bifurcación entre repositorios (consulta Acerca de las bifurcaciones)
• GitHub Actions secretos, variables, ambientes, ejecutores autohospedados, ejecutor más grandes o historial de ejecución de flujo de trabajo
• GitHub Apps e instalaciones de aplicaciones de GitHub
• Los objetos de Git LFS y los archivos binarios grandes (los repositorios que usan Git LFS siguen siendo compatibles, consulta Limitaciones de GitHub Enterprise Importer)
• Vínculos de confirmaciones a solicitudes de cambios fusionadas mediante cambio de base
• Paquetes en GitHub Packages
• Projects (la nueva experiencia de proyectos)
• Referencias entre las solicitudes de cambios y las incidencias en los distintos repositorios (consulta Referencias y direcciones URL autovinculadas)
• Estados de corrección de los resultados de secret scanning
• Repositorios propiedad de cuentas de usuario
• Fuente de actividad del repositorio
• Propiedades del repositorio
• Estrellas del repositorio
• Observadores del repositorio
• Conjuntos de reglas
• Reglas de protección de etiquetas
• Perfiles de los usuarios, claves SSH, claves de firma o personal access tokens
• Secretos de webhook
• Acceso de usuario al repositorio

Al migrar un repositorio directamente, no se migran los equipos ni el acceso de equipo a los repositorios.

Protecciones de rama

Las protecciones de rama aplican un conjunto especificado de reglas a un nombre de rama concreto o patrón de nombre de rama. Para más información, consulta Acerca de las ramas protegidas.

Las protecciones de rama siempre se migrarán, pero algunas reglas no. Las siguientes reglas de protección de rama no se migran.

• Permitir que actores específicos omitan las solicitudes de incorporación de cambios necesarias
• Exigir aprobación de la inserción más reciente
• Implementaciones correctas obligatorias antes de la combinación
• Bloqueo de una rama
• Restricción de inserciones que crean ramas coincidentes
• Permitir las subidas forzadas

También se aplican las siguientes limitaciones:

• Si una regla de protección de rama permite especificar opcionalmente personas, equipos o aplicaciones que están exentas de la regla, como "Restringir quién puede descartar las revisiones de solicitudes de incorporación de cambios", las excepciones no se migrarán.
• Si la regla "Permitir inserciones forzadas" está habilitada en el modo "Especificar quién puede forzar la inserción", la regla no se migrará.

Limitaciones de los datos migrados

There are limits to what GitHub Enterprise Importer can migrate. Some are due to limitations of GitHub, while others are limitations of GitHub Enterprise Importer itself.

Limitations of GitHub

• 2 GB size limit for a single Git commit: No single commit in your Git repository can be larger than 2 GB. If any of your commits are larger than 2 GB, you will need to split the commit into smaller commits that are each 2 GB or smaller.
• 255 byte limit for Git references: No single Git reference, commonly known as a "ref", can have a name larger than 255 bytes. Usually, this means that your references cannot be more than 255 characters long, but any non-ASCII characters, such as emojis, may consume more than one byte. If any of your Git references are too large, we'll return a clear error message.
• 100 MB file size limit: After you complete your migration, no single file in your Git repository can be larger than 100 MB. During repository migration this limit is increased to 400 MB. Consider using Git LFS to store large files. For more information, see Administrar archivos grandes.

Limitaciones de GitHub Enterprise Importer

• 40 GB size limit for a Git repository (versión preliminar pública): This limit applies only to the source code. To check if the repository archive is over the limit, use the git-sizer tool and review the total blob size in the output. The git-sizer tool also helps to identify potential issues related to large files, blob size, commit size, and tree counts that could impact migrations.
• Límite de 40 GB para metadatos (versión preliminar pública): Importer no puede migrar repositorios con más de 40 GB de metadatos. Los metadatos incluyen incidencias, solicitudes de incorporación de cambios, versiones y datos adjuntos. En la mayoría de los casos, los metadatos grandes se deben a los recursos binarios asociados a las versiones. Puedes excluir las versiones de la migración con la marca migrate-repo del comando --skip-releases y, después, mover las versiones manualmente después de la migración.
• 400 MB file size limit: When migrating a repository with GitHub Enterprise Importer, no single file in your Git repository can be larger than 400 MB. Consider using Git LFS for storing large files. For more information, see Administrar archivos grandes.
• Git LFS objects not migrated: The Importer can migrate repositories that use Git LFS, but the LFS objects themselves will not be migrated. They can be pushed to your migration destination as a follow-up task after the migration is complete. For more information, see Duplicar un repositorio.
• Follow-up tasks required: When migrating between GitHub products, certain settings are not migrated and must be reconfigured in the new repository. For a list of follow-up tasks you'll need to complete after each migration, see Introducción a una migración entre productos de GitHub.
• Delayed code search functionality: Re-indexing the search index can take a few hours after a repository is migrated, and code searches may return unexpected results until re-indexing is complete.
• Rulesets configured for your organization can cause migrations to fail: For example, if you configured a rule that requires email addresses for commit authors to end with @monalisa.cat, and the repository you're migrating contains commits that don't comply with this rule, your migration will fail. For more information about rulesets, see Acerca de los conjuntos de reglas.
• Mannequin content might not be searchable: Mannequins are placeholder users to which imported content (such as issues, pull requests, comments, etc.) is associated. When you search for content associated with a mannequin, such as assigned issues, the issues may not be found. Once a mannequin is reclaimed, the content should be found via the new owner. For more information, see Reclamación de maniquíes para GitHub Enterprise Importer.

Introducción

Antes de migrar entre los productos de GitHub, debe planear cómo ejecutará la migración. Antes de migrar los datos, deberá elegir a alguien para ejecutar la migración. Debe conceder a esa persona el acceso necesario para el origen y el destino de la migración. También le recomendamos ejecutar primero una migración de prueba.

Para obtener información general sobre el proceso de migración de principio a fin, consulta Introducción a una migración entre productos de GitHub.