- ¿Cuándo es necesaria una migración?
- Qué debes tener en cuenta durante el traslado
- Crear un proyecto nuevo en el servidor de destino
- GitLab
- GitHub
- Transferir el repositorio Git al servidor nuevo
- 1. Comprobar si existe un remote origin antiguo
- 2. Establecer la URL remota del proyecto nuevo
- 3. Transferir todas las ramas locales
- 4. Transferir las etiquetas
- Tabla: diferencias entre los principales comandos git push
- Migración a GitLab o GitHub
- Diferencias entre GitHub y GitLab
- Resumen de las diferencias principales
- ¿Qué sistema resulta más adecuado para cada uso?
- Diferencias durante la migración
- Recomendaciones y buenas prácticas
- FAQ
- ¿Puedo transferir issues, merge requests o contenidos de la wiki?
- ¿Qué ocurre si el proyecto de destino ya contiene archivos?
- ¿Qué ocurre con las ramas antiguas que existían en el servidor pero no localmente?
- ¿Tengo que cambiar el nombre de la rama master a main?
Cuando quieres trasladar un repositorio Git existente a un servidor nuevo, es habitual preguntarse cómo funciona técnicamente la migración y qué aspectos debes tener en cuenta. Esto resulta especialmente importante cuando el servidor antiguo ya no está disponible o has perdido el acceso, por ejemplo al cambiar de un servidor GitLab autoalojado a GitLab.com o GitHub.
En este artículo explico paso a paso cómo funciona la migración, qué comandos Git son importantes y en qué casos cambia el procedimiento. También describo problemas habituales, alternativas y respuestas a preguntas frecuentes.
¿Cuándo es necesaria una migración?
Situaciones habituales:
- El servidor Git antiguo ya no está disponible.
- Solo conservas un repositorio local en el ordenador o el servidor.
- El servidor antiguo ya no te pertenece, por ejemplo tras cambiar de empresa.
- Un proyecto debe trasladarse de forma centralizada a GitLab.com o GitHub.
- Quieres consolidar varios repositorios.
En estas situaciones debes saber si todavía dispones de todos los datos antiguos o únicamente de una copia local correspondiente a la última clonación.
Qué debes tener en cuenta durante el traslado
Antes de migrar un repositorio Git, comprueba estos puntos:
- ¿Todavía tienes acceso al servidor antiguo?
Si es así, puedes usargit push --mirrory transferir realmente todo. - ¿Solo conservas una copia local?
En ese caso solo puedes transferir las ramas y etiquetas disponibles localmente. - ¿Se utilizaron merge requests, issues, wikis o pipelines?
Estos datos no forman parte del repositorio y no pueden transferirse mediante Git. - GitLab y GitHub solo transfieren datos Git mediante git push, keine Server-Metadaten.
Crear un proyecto nuevo en el servidor de destino
Tanto si utilizas GitLab como GitHub, primero debes crear un proyecto nuevo y vacío.
GitLab
- Abrir el grupo
- « New project »
- « Create blank project »
- Desactiva « Initialize repository with a README » si quieres realizar una migración
(de lo contrario, se producirá un conflicto durante el push)
GitHub
- Repositories
- « New »
- Elegir « Repository name »
- No crear README ni .gitignore
- Crear el repositorio
Transferir el repositorio Git al servidor nuevo
1. Comprobar si existe un remote origin antiguo
git remote -v
2. Establecer la URL remota del proyecto nuevo
git remote set-url origin <NEUE-URL>
Ejemplo para GitLab:
https://gitlab.com/benutzer/projekt.git
Ejemplo para GitHub:
https://github.com/benutzer/projekt.git
3. Transferir todas las ramas locales
Si el servidor antiguo ya no está disponible:
git push -u origin --all #alternativ kann auch git push --mirror origin verwendet werden
Este comando transfiere:
- todas las ramas locales
- incluidas master o main
- y configura el seguimiento para futuros pushs
4. Transferir las etiquetas
Si el proyecto utilizaba etiquetas:
git push origin --tags
Tabla: diferencias entre los principales comandos git push
| Comando | Función | Recomendación |
|---|---|---|
git push --mirror origin | Copia todas las ramas, etiquetas, configuraciones remotas y referencias | Utilizar solo si el servidor antiguo sigue disponible |
git push -u origin --all | Transfiere todas las ramas locales | Método estándar para migrar sin el servidor antiguo |
git push origin --tags | Transfiere todas las etiquetas | Ejecutar después del push de las ramas |
git push -f origin | Fuerza la sobrescritura de la rama de destino | Solo si hay conflictos con un repositorio de destino vacío |
git remote set-url origin <URL> | Cambia la dirección remota | Paso principal de la migración |
Migración a GitLab o GitHub
| Tema | GitLab | GitHub |
|---|---|---|
| Iniciar el proyecto sin README | Posible | Posible |
| Funciones de importación en la interfaz web | Muy completas | Completas, pero menos que en GitLab |
| Transferencia de issues | No, salvo mediante API o exportaciones | No |
| Comandos push idénticos | Sí | Sí |
| Migración de LFS | Compatible | Compatible |
En la práctica no hay grandes diferencias, ya que ambas plataformas admiten Git de forma nativa. La migración utiliza los mismos comandos en ambas.
Diferencias entre GitHub y GitLab
Aunque GitHub y GitLab parecen muy similares a primera vista y ambos funcionan perfectamente como servidores Git, existen diferencias que pueden ser relevantes al migrar un repositorio o trabajar a largo plazo. Muchos principiantes se preguntan si trasladarse a GitHub funciona de forma distinta que hacerlo a GitLab o si faltan determinadas funciones. La buena noticia es que los comandos Git son idénticos en ambas plataformas, aunque estas difieren claramente en algunos aspectos.
Resumen de las diferencias principales
| Área | GitHub | GitLab |
|---|---|---|
| Enfoque | La mayor plataforma de desarrollo del mundo, muy orientada a la comunidad | Plataforma DevOps con CI/CD y gestión de proyectos integrados |
| Repositorios privados | Gratuitos, pero con funciones limitadas | Gratuitos y con numerosas funciones, también para equipos |
| CI/CD | GitHub Actions, muy flexible | GitLab CI/CD integrado de forma nativa |
| Estructura de proyectos | Estructura plana centrada en repositorios | Potente estructura de grupos y subgrupos |
| Gestión de issues | Sencilla y clara | Más completa, con tableros, epics y hojas de ruta |
| Wikis | Por repositorio | Por proyecto, con más funciones de administración |
| Herramientas de importación | Buenas, pero menos completas que las de GitLab | Funciones de importación muy completas para GitHub, Bitbucket, Jira, etc. |
| Autoalojamiento | GitHub Enterprise, caro | GitLab puede autoalojarse por completo; Community Edition es gratuita |
| Gestión de permisos | Sencilla | Muy detallada y basada en roles |
| Almacenamiento gratuito | Limitado para LFS | Más espacio gratuito para repositorios y el registro de contenedores |
¿Qué sistema resulta más adecuado para cada uso?
GitHub es ideal si:
- inicias un proyecto de código abierto
- quieres incluir a muchos desarrolladores externos
- buscas una gran comunidad y muchas integraciones listas para usar
- quieres utilizar GitHub Actions
GitLab es ideal si:
- buscas una solución DevOps completa
- quieres organizar muchos proyectos en grupos
- necesitas autoalojamiento o un control total
- quieres utilizar CI/CD sin herramientas adicionales
Diferencias durante la migración
Para migrar el repositorio Git apenas importa si utilizas GitHub o GitLab, ya que ambos admiten los mismos estándares de Git. Las diferencias se encuentran principalmente en el entorno:
- GitHub crea automáticamente la rama main, GitLab solo lo hace de forma opcional.
- Después del push, GitLab muestra automáticamente indicaciones para crear merge requests.
- GitHub da más importancia a las pull requests que a las merge requests.
- GitLab admite repositorios espejo de forma nativa; GitHub requiere automatización o Actions.
- GitLab ofrece completos asistentes de importación para transferir proyectos de GitHub con sus issues.
Recomendaciones y buenas prácticas
- ¿Proyecto público o privado? Defínelo previamente en el proyecto de destino.
- ¿Clave SSH o HTTPS? SSH evita introducir contraseñas constantemente.
- Comprueba las ramas locales antes de subirlas.
- Elimina previamente las ramas antiguas que ya no sean necesarias.
- Después del push, comprueba que todas las ramas y etiquetas se hayan transferido correctamente.
FAQ
¿Puedo transferir issues, merge requests o contenidos de la wiki?
No. Estos datos se encuentran en el servidor y no en el repositorio Git. Solo pueden migrarse mediante exportaciones o API.
¿Qué ocurre si el proyecto de destino ya contiene archivos?
Se producirán conflictos. Lo mejor es crear el proyecto de destino completamente vacío.
¿Qué ocurre con las ramas antiguas que existían en el servidor pero no localmente?
Se perderán si ya no tienes acceso al servidor antiguo.
¿Tengo que cambiar el nombre de la rama master a main?
No. GitLab y GitHub aceptan ambos nombres.
Este artículo ha sido traducido con ayuda de IA.