# GitLab: qué es y cómo trabajar con él mediante Git (clone, push, merge request, CI/CD)

URL: https://skillaria.top/es/guides/git/que-es-gitlab

GitLab es una plataforma web para guardar repositorios Git y trabajar en equipo: código, merge requests, tareas e integración continua (CI/CD) en un mismo lugar. Puedes usarlo en la nube, en gitlab.com, o en un servidor propio de la empresa, y el código se envía y se descarga con los comandos habituales de Git: clone, push y pull.

## GitLab: qué es

GitLab es una plataforma donde se guardan los repositorios Git y se organiza el trabajo en equipo: revisión del código, merge requests (solicitudes de fusión), tareas, wiki, registro de contenedores e integración continua (CI/CD). Dicho de forma breve, GitLab es «GitHub con su propio sistema de compilación y la posibilidad de instalarlo en tu servidor». Muchas empresas, sobre todo en países de habla hispana, guardan el código en GitLab instalado en su red interna.

El proyecto empezó en 2011 como una aplicación abierta para alojar código; después se formó alrededor de ella la empresa GitLab Inc. La plataforma existe en dos variantes: Community Edition, abierta y gratuita para instalar en tu servidor, y Enterprise Edition, con funciones de pago. En gitlab.com los planes se llaman Free, Premium y Ultimate.

Conviene no confundir los conceptos. Git es el sistema de control de versiones, un programa en tu ordenador. GitLab es un servicio que guarda una copia remota del repositorio y añade una interfaz y herramientas para el equipo. Sin Git no se puede trabajar con GitLab, pero Git funciona perfectamente sin GitLab.

## Git y GitLab: cuál es la diferencia

Las búsquedas «git y gitlab qué es» suelen surgir cuando en una oferta de trabajo o en el primer día laboral aparecen las dos palabras. La diferencia es la misma que entre un documento y un almacenamiento en la nube: Git registra los cambios de los archivos, el historial de commits y las ramas en tu equipo. GitLab recibe ese historial por la red y lo muestra en el navegador.

|  | Git | GitLab |
| --- | --- | --- |

| Qué es | Programa de control de versiones | Plataforma web para repositorios y trabajo en equipo |

| Dónde funciona | En el ordenador del desarrollador | En gitlab.com o en el servidor de la empresa |

| Necesita internet | No, salvo para push, pull, fetch y clone | Sí, es un servicio en red |

| Lo principal | Commits, ramas, fusiones, historial | Merge request, revisión, tareas, CI/CD, permisos de acceso |

| Cómo se usa | Línea de comandos, IDE, clientes gráficos | Navegador más los comandos habituales de Git |

Todas las acciones con el código —commit, branch, merge— se siguen haciendo en Git. GitLab solo recibe el resultado con `git push` y permite discutirlo con los compañeros.

## GitLab y GitHub: en qué se diferencian

Ambos servicios guardan repositorios Git y permiten la revisión del código, así que las habilidades básicas se trasladan tal cual. Las diferencias están en los énfasis y en el modelo de despliegue.

| Criterio | GitLab | GitHub |
| --- | --- | --- |

| Solicitud de fusión | Merge request (MR) | Pull request (PR) |

| CI/CD | GitLab CI/CD integrado, archivo `.gitlab-ci.yml` | GitHub Actions, archivos en `.github/workflows/` |

| Instalación propia | Community Edition gratuita en tu servidor | GitHub Enterprise Server, de pago |

| Código fuente de la plataforma | Abierto (Community Edition) | Cerrado |

| Agrupación de proyectos | Grupos y subgrupos anidados | Organizaciones |

| Dónde es más popular | Desarrollo corporativo, servidores internos | Open source, proyectos públicos, portafolio |

En la práctica, muchos desarrolladores usan los dos: los proyectos personales y el portafolio están en GitHub, y el código de trabajo, en el GitLab corporativo. Los comandos de Git son los mismos; solo cambia la dirección del repositorio remoto.

## gitlab.com o servidor propio (self-hosted)

El gitlab.com en la nube es adecuado para proyectos personales y equipos pequeños: te registras y creas repositorios al momento. Las actualizaciones, las copias de seguridad y la disponibilidad corren a cargo de GitLab. Las limitaciones del plan gratuito (número de participantes, minutos de CI, espacio de almacenamiento) cambian de vez en cuando, así que consulta las condiciones actuales en la página de precios.

GitLab autohospedado (self-hosted) lo instala la empresa en su servidor: desde el paquete para Linux, en Docker o en Kubernetes. El código no sale de la red interna, se puede conectar el acceso corporativo mediante LDAP y configurar runners propios para las compilaciones. A cambio, los administradores responden de las actualizaciones y las copias de seguridad. Para el desarrollador la diferencia casi no se nota: la dirección no será `gitlab.com`, sino, por ejemplo, `gitlab.empresa.com`.

## Configurar Git para trabajar con GitLab

Antes del primer commit, indica tu nombre y tu correo electrónico: aparecerán en el historial, y GitLab asociará los commits a tu perfil por el correo:

```
git config --global user.name "Iván Pérez"
git config --global user.email "ivan@example.com"
```

En Windows es cómodo trabajar en Git Bash: se instala junto con Git para Windows e incluye `ssh-keygen`, así que todos los comandos de este artículo funcionan en él sin cambios. Después hay que elegir el método de acceso: HTTPS con token o clave SSH.

### Acceso por HTTPS: personal access token

Para las operaciones de Git por HTTPS no conviene usar la contraseña de la cuenta, y si tienes activada la autenticación de dos factores, ni siquiera funciona. En su lugar, crea un personal access token en la configuración del perfil de GitLab (sección Access tokens). Para trabajar con código basta con los permisos `read_repository` y `write_repository`; define una fecha de caducidad y guarda el token de inmediato, porque no se vuelve a mostrar.

Al primer push o clone, Git pide usuario y contraseña: escribe tu nombre de usuario de GitLab y, en lugar de la contraseña, el token. El gestor de credenciales (en Git para Windows viene integrado) lo recordará y ya no tendrás que volver a escribirlo.

### Acceso por clave SSH

SSH resulta más cómodo para el día a día: añades la clave una vez y ya no tienes que escribir nada más.

```
ssh-keygen -t ed25519 -C "ivan@example.com"
cat ~/.ssh/id_ed25519.pub
```

El contenido del archivo `.pub` (la clave pública) se pega en la configuración del perfil de GitLab, en la sección SSH Keys. Para comprobar la conexión:

```
ssh -T git@gitlab.com
Welcome to GitLab, @ivan.perez!
```

## Git clone de GitLab: cómo clonar un repositorio

En la página del proyecto hay un botón Code con dos direcciones, para SSH y para HTTPS. Copia la que necesites y ejecuta `git clone`:

```
# por HTTPS
git clone https://gitlab.com/mi-grupo/mi-proyecto.git

# por SSH
git clone git@gitlab.com:mi-grupo/mi-proyecto.git
```

En GitLab, la ruta del proyecto puede incluir subgrupos, por ejemplo `gitlab.com/empresa/backend/api.git`. Es normal: copia la dirección completa.

### Git clone de GitLab con token

En scripts y servidores donde nadie puede escribir una contraseña, el token se pasa directamente en la dirección. El usuario puede ser tu nombre de usuario o el nombre de servicio `oauth2`:

```
git clone https://oauth2:TU_TOKEN@gitlab.com/mi-grupo/mi-proyecto.git
```

Ojo: esa dirección se guarda en `.git/config` y puede acabar en el historial de comandos. Para la automatización es mejor usar un deploy token o un project access token con permisos mínimos y caducidad limitada, y en CI, la variable integrada `CI_JOB_TOKEN`.

## Git push a GitLab: enviar el código

Si el proyecto ya existe en local, crea un proyecto vacío en GitLab (sin README, para no generar un commit extra) y vincula el repositorio remoto:

```
git remote add origin git@gitlab.com:mi-grupo/mi-proyecto.git
git branch -M main
git push -u origin main
```

La opción `-u` vincula la rama local con la remota; después basta con escribir `git push` y `git pull`. El ciclo de trabajo normal no se diferencia de cualquier otro servicio:

```
git switch -c feature/login
git add .
git commit -m "Añadir formulario de inicio de sesión"
git push -u origin feature/login
git pull
```

Las etiquetas se envían aparte: `git push origin v1.2.0`, o todas a la vez con `git push --tags`. En GitLab las etiquetas aparecen en la sección Tags y a menudo disparan un pipeline de publicación de versión.

### Errores típicos de git push en GitLab

- **HTTP Basic: Access denied**: usuario incorrecto o se escribió la contraseña en lugar del token. Crea un token con el permiso `write_repository` y borra la entrada antigua del gestor de credenciales.
- **Permission denied (publickey)**: GitLab no reconoce la clave SSH. Comprueba que la clave pública está añadida al perfil y ejecuta `ssh -T git@gitlab.com`.
- **You are not allowed to push code to protected branches**: la rama (normalmente `main`) está protegida. Envía los cambios a tu rama y abre un merge request.
- **rejected ... (fetch first)**: en el servidor hay commits que tú no tienes. Ejecuta `git pull --rebase` y repite el push.
- **remote: Project not found**: errata en la dirección o no tienes acceso al proyecto; pide al propietario que confirme tu rol.

## Merge request en GitLab

El merge request es el equivalente al pull request de GitHub: la petición de fusionar tu rama en la principal. Es en el MR donde los compañeros dejan comentarios en las líneas de código, se ejecutan las comprobaciones de CI y se decide la fusión. Tras el push de una rama nueva, GitLab muestra en la terminal un enlace para crear el MR, y en la interfaz web aparece la propuesta de crearlo.

El MR también se puede crear desde la línea de comandos con las opciones de push:

```
git push -o merge_request.create -o merge_request.target=main origin feature/login
```

El proceso típico es: rama para la tarea → commits → push → MR → revisión y pipeline en verde → merge. Al fusionar, GitLab puede combinar los commits en uno (squash) y borrar la rama de origen. Si el MR tiene conflictos, lo más sencillo es actualizar la rama en local con `git pull --rebase origin main` o `git merge main`, resolver los conflictos y volver a hacer push.

Marca el trabajo no terminado como Draft: un MR así no se puede fusionar por error, pero los compañeros ya ven los cambios y pueden comentarlos.

## CI/CD en GitLab: .gitlab-ci.yml

La característica principal de GitLab es su CI/CD integrado. Basta con colocar en la raíz del repositorio un archivo `.gitlab-ci.yml` para que, en cada push, GitLab ejecute un pipeline formado por etapas (stages) y tareas (jobs). Las tareas las ejecutan los runners: en gitlab.com hay runners compartidos; en un servidor propio se instalan aparte.

```
stages:
  - test
  - deploy

test:
  stage: test
  image: python:3.12
  script:
    - pip install -r requirements.txt
    - pytest

deploy:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: $CI_COMMIT_TAG
```

Aquí las pruebas se ejecutan en cada push, y la tarea `deploy` solo cuando se envía una etiqueta: `git tag v1.0.0` y `git push origin v1.0.0`. Los resultados del pipeline se ven directamente en el merge request, y puedes impedir la fusión mientras las comprobaciones no pasen.

## Cómo borrar un repositorio en GitLab

Los comandos de Git no pueden eliminar un proyecto del servidor: `git push` solo cambia ramas y etiquetas. El proyecto se elimina en la interfaz web: configuración del proyecto, sección General, bloque Advanced, botón de eliminar con confirmación escribiendo el nombre. Hace falta el rol de Owner. La copia local permanece: es solo una carpeta con `.git`.

Si quieres desvincular el repositorio local de GitLab sin borrar nada en el servidor, basta con `git remote remove origin`.

## Cuándo elegir GitLab

- El código no puede salir a una nube externa: hace falta un servidor propio.
- Necesitas CI/CD listo para usar, sin servicios de terceros.
- Eres una organización grande con una jerarquía de equipos: te servirán los subgrupos y los roles flexibles.
- Te incorporas a una empresa que ya usa GitLab: entonces no hay elección, pero las habilidades con Git se trasladan por completo.

Para portafolio y open source suele elegirse GitHub, porque tiene una comunidad más grande y mayor visibilidad de los proyectos. Nada impide tener un proyecto en ambos servicios: un repositorio puede tener varios remotos.

## Resumen

GitLab es una plataforma para repositorios Git con revisión mediante merge requests, tareas y CI/CD integrado, disponible tanto en la nube como en servidor propio. Trabajar con ella se reduce a comandos conocidos: configura el acceso con token o clave SSH y después clone, commit, push y merge request. Los repositorios remotos y los flujos de trabajo en equipo se explican con práctica en el curso de Git.

## FAQ

**¿GitLab es gratis?**

La Community Edition para instalar en tu servidor es gratuita; en gitlab.com existe el plan gratuito Free, con limitaciones. Las funciones avanzadas están en los planes de pago Premium y Ultimate.

**¿Se puede migrar un proyecto de GitHub a GitLab?**

Sí: GitLab permite importar proyectos desde GitHub, y el historial también se puede trasladar a mano con git clone --mirror de la dirección antigua y git push --mirror a la nueva.

**¿Hay que aprender comandos específicos para GitLab?**

No; el código se gestiona con los comandos normales de Git. GitLab añade la interfaz web, y para automatizar existen la utilidad de consola glab y la API.

**¿En qué se diferencia GitLab Flow de Git Flow?**

GitLab Flow es más sencillo: el trabajo se hace en ramas de funcionalidad con merge requests hacia main, y para entornos y versiones, si hace falta, se añaden ramas propias, sin las ramas develop y hotfix de Git Flow.


---
Source: Skillaria.Top (https://skillaria.top)