Del primer inicio de sesión al Merge Request aprobado.
Esta guía recorre, paso a paso, cómo asegurar tu cuenta, entender la estructura de ramas del equipo y completar el flujo de trabajo en GitLab, desde clonar un proyecto hasta fusionar tus cambios.
Primeros pasos en la plataforma
Antes de trabajar en cualquier proyecto, tu cuenta debe pasar por cuatro configuraciones obligatorias, en este orden: cambio de contraseña, autenticación de dos factores, claves SSH y token de acceso personal.
Primer acceso y cambio de contraseña
Ingresa a gitlab.posgradoupea.edu.bo. En tu primer inicio de sesión, el sistema exigirá cambiar la contraseña. La nueva debe cumplir la política institucional:
Ejemplo de contraseña válida:
Post9rado#UPEA25!
Generador de contraseñas seguras de 1PasswordGuarda tu contraseña únicamente en un gestor de contraseñas confiable (como 1Password o Bitwarden). Evita anotarla en notas sin cifrar, hojas de cálculo o mensajes de chat y correo.
Autenticación de dos factores (2FA)
Obligatoria para todos los usuarios: añade un código temporal generado por una app en tu teléfono, además de la contraseña.
Código de 6 dígitos generado por la app
Conserva siempre el acceso a la aplicación de autenticación elegida. Perderlo puede impedirte temporalmente el acceso a tu cuenta.
Configuración de claves SSH
Permiten interactuar con GitLab (clonar, hacer push/pull) sin escribir la contraseña en cada operación. Se recomienda el algoritmo Ed25519.
Token de Acceso Personal (PAT)
Credencial alternativa a la contraseña para autenticar operaciones Git vía HTTPS y herramientas de automatización.
Configuración completada
Con la contraseña cambiada, el 2FA activo, las claves SSH registradas y el PAT generado (si lo necesitas), tu cuenta está lista. Formarás parte del equipo TeamPSG de Posgrado UPEA. Cuando te asignen proyectos y permisos, podrás clonar repositorios y participar en el flujo descrito a continuación.
Estructura de ramas y permisos
Cuando un administrador o Maintainer te invite a un proyecto, obtienes acceso al repositorio según el rol y permisos otorgados.
Ramas protegidas: develop y main
Todo proyecto mantiene dos ramas permanentes y protegidas. Ningún rol desarrollador, salvo Maintainer, puede hacer push directo a ellas: todo cambio pasa obligatoriamente por un Merge Request aprobado.
| Rama | Entorno | Quién puede modificarla |
|---|---|---|
| develop | Preproducción | Solo vía MR aprobado |
| main | Producción | Solo vía MR aprobado |
Las ramas tipo feature (y equivalentes) son temporales: nacen para desarrollar una funcionalidad y se eliminan automáticamente cuando el MR correspondiente se aprueba y fusiona.
Convención de nombres de ramas
Toda rama debe nombrarse según el tipo de cambio, con el prefijo correspondiente seguido de una descripción breve en minúsculas separada por guiones.
| Prefijo | Uso | Ejemplo |
|---|
Más ejemplos correctos:
El nombre de la rama debe describir en pocas palabras qué se está haciendo, usando minúsculas y guiones en vez de espacios.
Flujo de trabajo completo, paso a paso
Esta es la secuencia estándar que todo desarrollador debe seguir en cualquier proyecto de la institución, tanto en projects/main/ como en projects/internal/.
Archivos esenciales del repositorio
Independientemente del tipo de proyecto (API, frontend u otro), todo repositorio debe incluir, además del código de la aplicación, un conjunto de archivos de soporte que faciliten el desarrollo local, la colaboración del equipo y el paso a producción.
Estos archivos normalmente se agregan en el primer commit del proyecto, en la rama feature/carga-inicial (ver Parte 2), antes de comenzar a desarrollar funcionalidades.
El repositorio infraestructura
Además de tu repositorio de servicio (api, frontend, u otro), cada proyecto cuenta con un repositorio hermano de nombre fijo: infraestructura. Ahí vive todo lo necesario para llevar el proyecto completo a preproducción (test) y a producción.
Dentro de infraestructura se encuentra:
El Dockerfile.dev de tu repositorio es de uso exclusivo para desarrollo local. Es una plantilla: dentro de infraestructura se crea, a partir de ella, el Dockerfile real usado en test y producción, con los ajustes necesarios (build en varias etapas, usuario sin privilegios de administrador, eliminación de dependencias de desarrollo, entre otros). Si ese Dockerfile final difiere del tuyo, es intencional: la persona responsable del despliegue documenta esas diferencias para que tu equipo las conozca.
No crees un Dockerfile de producción ni un docker-compose.yml que orqueste todo el proyecto dentro de tu repositorio de servicio. Ambos pertenecen únicamente a infraestructura.
Crear y gestionar el Merge Request
Una vez enviada la rama al repositorio remoto, debes crear un Merge Request para solicitar la integración de tus cambios en la rama principal del proyecto.
El ciclo de revisión se repite sobre el mismo MR hasta que es aprobado (o cerrado). Al aprobarse, el flujo continúa hacia el merge y la limpieza de la rama.
Buenas prácticas generales
Nueve recomendaciones que mantienen el repositorio limpio y el flujo de trabajo predecible para todo el equipo.
Resumen visual del flujo completo
| Etapa | Comando / Acción clave |
|---|
Has completado el recorrido.
Ya conoces la configuración de cuenta, la estructura de ramas y el flujo completo de trabajo con Merge Requests en GitLab.