Acerca de las migraciones entre productos de GitHub

Acerca de las migraciones entre productos de GitHub

Con GitHub Enterprise Importer, puede migrar datos de GitHub Enterprise Server a GitHub Enterprise Cloud, o migrar datos entre cuentas de GitHub Enterprise Cloud. Para obtener más información, vea «Acerca de GitHub Enterprise Importer».

Si el origen de la migración es otra cuenta en GitHub.com, puede 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.

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.

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
Proyectos (clásicos) en el nivel de repositorio
Flujos de trabajo de GitHub Actions
Comentarios sobre confirmación de cambios
Webhooks activos
Protecciones de rama
Configuración de GitHub Pages
Historial de usuarios de los datos anteriores
Elementos adjuntos (véase "Adjuntar archivos")
Lanzamientos

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

Actualmente, no se migran los datos siguientes.

• Cualquier instancia de Projects (la nueva experiencia de proyectos)
• 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
• Secretos de GitHub Codespaces
• 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
• 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
• Propiedades del repositorio (beta pública)
• 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 otras cuentas en GitHub.com

Si el origen de la migración es otra cuenta en GitHub.com, puede 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; consulte "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 obtener más información, vea «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)
• Proyectos (clásicos) en el nivel de repositorio
• Flujos de trabajo de GitHub Actions
• Comentarios sobre confirmación de cambios
• Webhooks activos (deben volver a habilitarse después de la migración; consulte "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 (véase "Adjuntar archivos")

Actualmente, no se migran los datos siguientes.

• Cualquier instancia de Projects (la nueva experiencia de proyectos)
• 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
• Secretos de GitHub Codespaces
• 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
• 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
• Propiedades del repositorio (beta pública)
• 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.com, mientras que otras son limitaciones propias de GitHub Enterprise Importer.

Limitaciones de GitHub.com

• 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, consulte "Introducción a una migración entre productos de GitHub".