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

git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror

git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror

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.

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

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")
• Paquetes en GitHub Packages
• Proyectos (clásicos) en el nivel de organización
• Projects (la nueva experiencia de proyectos)
• Referencias entre las solicitudes de incorporación de cambios y los problemas 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
• 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 obtener más información, vea «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 GitHub Advanced Security
  • 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")
• Paquetes en GitHub Packages
• Proyectos (clásicos) en el nivel de organización
• Projects (la nueva experiencia de proyectos)
• Referencias entre las solicitudes de incorporación de cambios y los problemas 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
• 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 obtener más información, vea «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

Hay límites con respecto a lo que GitHub Enterprise Importer puede migrar. Algunos se deben a limitaciones de GitHub, mientras que otras son limitaciones propias de GitHub Enterprise Importer.

Limitaciones de GitHub

• Límite de tamaño de 2 GB para una única confirmación de Git: ninguna confirmación en el repositorio de Git puede ser superior a 2 GB. Si alguna de las confirmaciones es superior a 2 GB, tendrás que dividirla en confirmaciones más pequeñas, cada una de 2 GB o menos.
• Límite de 255 bytes para las referencias de Git: ninguna referencia de Git, conocida normalmente como "ref", puede tener un nombre de más de 255 bytes. Normalmente, esto significa que las referencias no pueden tener más de 255 caracteres, pero cualquier carácter no ASCII, como los emojis, puede consumir más de un byte. Si alguna de las referencias de Git es demasiado grande, se devolverá un mensaje de error claro.
• Límite de tamaño de archivo de 100 MB: ningún archivo en el repositorio de Git puede ser superior a 100 MB. Considera la posibilidad de usar Git LFS para almacenar archivos grandes. Para obtener más información, vea «Administrar archivos grandes».

Limitaciones de GitHub Enterprise Importer

• Límite de tamaño de 10 GB para un repositorio de Git: este límite solo se aplica al código fuente. Para comprobar si el archivo del repositorio supera el límite, use la herramienta git-sizer y revise el tamaño total del blob en la salida. La herramienta git-sizer también ayuda a identificar posibles problemas relacionados con archivos de gran tamaño, tamaño de blob, tamaño de confirmación y recuentos de árboles que podrían afectar a las migraciones.
• Límite de 10 GB para metadatos: Importer no puede migrar repositorios con más de 10 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.
• Objetos de Git LFS no migrados: Importer puede migrar repositorios que usan Git LFS, pero los propios objetos LFS no se migrarán. Se pueden insertar en el destino de la migración como una tarea de seguimiento una vez que se complete la migración. Para obtener más información, vea «Duplicar un repositorio».
• Tareas de seguimiento necesarias: al realizar la migración entre productos de GitHub, determinadas configuraciones no se migran y se deben volver a configurar en el nuevo repositorio. Para obtener una lista de las tareas de seguimiento que necesitarás completar después de cada migración, consulta "Introducción a una migración entre productos de GitHub".
• Funcionalidad de búsqueda de código retrasada: volver a indexar el índice de búsqueda puede tardar unas horas después de migrar un repositorio y las búsquedas de código pueden devolver resultados inesperados hasta que se complete la nueva indexación.
• Los conjuntos de reglas configurados para la organización pueden provocar errores en las migraciones: por ejemplo, si has configurado una regla que requiere que las direcciones de correo electrónico de los creadores de confirmaciones terminen en @monalisa.caty el repositorio que vas a migrar contiene confirmaciones que no cumplen esta regla, se producirá un error en la migración. Para obtener más información sobre los conjuntos de reglas, consulta "Acerca de los conjuntos de reglas".
• Es posible que el contenido de Mannequin no se pueda buscar: los maniquíes son usuarios de marcador de posición a los que está asociado el contenido importado (por ejemplo, problemas, solicitudes de incorporación de cambios, comentarios, etc.). Al buscar contenido asociado a un maniquí, como problemas asignados, es posible que no se encuentren los problemas. Una vez reclamado un maniquí, el contenido debe encontrarse a través del nuevo propietario. Para obtener más información, vea «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.