Trabajar con Git y GitLab en el DTI

Esta guía está pensada para quienes recién llegan al DTI y van a colaborar en alguno de nuestros proyectos. No asume conocimiento previo de Git. Si nunca has tocado un repositorio, este es el lugar para empezar.

1. ¿Qué es Git?

Imagínate un documento de Word donde colaboran cinco personas a la vez. Cada una escribe, borra, pega y guarda al mismo archivo. ¿Qué pasa? Que el archivo se rompe y nadie recuerda qué versión era la buena.

Git es la herramienta que evita ese caos en código. Sirve para:

• Guardar el historial de todos los cambios que se hacen sobre un proyecto.
• Permitir que varias personas trabajen al mismo tiempo sin pisarse.
• Volver a una versión anterior si algo sale mal.

Si Git es la libreta donde se anota cada cambio, GitLab es la oficina donde se guarda esa libreta y donde el equipo coordina su trabajo. El DTI tiene su propia oficina interna en gitlab.unach.cl.

2. ¿Qué es una rama?

Una rama (en inglés branch) es una copia temporal del proyecto sobre la que trabajas sin afectar al resto del equipo.

Una analogía simple: imagínate que el proyecto es un árbol. La rama principal es el tronco. Cuando tú quieres agregar algo nuevo, no escribes directo sobre el tronco; sales por una rama lateral, haces tu trabajo ahí, y cuando está listo y revisado, lo “pegas” de vuelta al tronco.

Esto tiene dos beneficios enormes:

1. No rompes lo que el resto está usando. Mientras tú trabajas en tu rama, los demás siguen viendo el tronco intacto.
2. Tu trabajo se puede revisar antes de juntarse con el tronco. Es la base del review por mentor DTI que verás más abajo.

3. Las tres ramas del DTI

En el DTI usamos exactamente tres tipos de rama, no más:

Regla de oro del DTI: cuando vayas a empezar una tarea nueva, saca tu rama feature/* desde staging, no desde main. Esto evita que tu trabajo parta sobre código no validado.

Ejemplos de nombres válidos de feature branches:

• feature/login-form — añadir formulario de login.
• feature/phone-field — añadir campo teléfono al perfil.
• feature/rut-validation — validar formato de RUT chileno.

4. Git en VSCode

En el DTI no necesitas usar terminal para el día a día. Todo se hace con el panel Source Control integrado en VSCode (el icono que parece una bifurcación en la barra lateral izquierda).

Pasos básicos:

1. Instala VSCode. Descárgalo desde code.visualstudio.com (gratis).
2. Clonar el proyecto desde gitlab.unach.cl. En VSCode: Ctrl+Shift+P → escribe “Git: Clone” → pega la URL del proyecto (tu mentor DTI te la pasa).
3. Cambiar a la rama staging. Abajo a la izquierda de VSCode aparece el nombre de la rama actual. Haz clic → elige staging.
4. Crear tu feature branch. Mismo dropdown → “Create new branch from…” → elige staging → escribe feature/nombre-corto.
5. Trabajar y hacer commit. Cuando termines un cambio pequeño y completo: abre el panel Source Control → escribe un mensaje (ej. feat: agregar campo teléfono) → presiona Ctrl+Enter o el botón ✓ Commit.
6. Subir tu rama a GitLab. En el panel: botón Sync Changes (o Publish Branch la primera vez). Esto envía tu rama a gitlab.unach.cl.

Mensajes de commit: usa el prefijo según el tipo de cambio: feat: (nueva funcionalidad), fix: (corrección de bug), docs: (documentación), chore: (mantención), refactor: (reorganización sin cambio de comportamiento).

5. GitLab UNACH paso a paso

Una vez que pushaste tu rama, hay que crear una Merge Request (MR) en GitLab para pedir que se integre.

1. Entra a gitlab.unach.cl y busca el proyecto correspondiente (Sigae, Sacint, Carga Horaria, etc.).
2. En el menú lateral izquierdo, ve a Merge requests.

3. Haz clic en + New merge request.
4. Source branch: tu feature/.... Target branch: staging (no main).
5. Escribe un título claro (usando el mismo prefijo del commit) y una breve descripción explicando qué hiciste y cómo probarlo.
6. Reviewer: asigna a tu mentor DTI.
7. Haz clic en Create merge request.

A partir de aquí tu trabajo queda esperando review. Verás un panel con el estado del pipeline (el CI/CD; lo explicamos en la sección 7).

6. El rol del mentor DTI

El mentor DTI es la persona que revisa y aprueba los cambios antes de que entren a staging o a main. Tiene dos responsabilidades clave:

1. Revisar tu MR a staging. Lee tu código, comenta lo que falte, te pide ajustes si los hay. Cuando todo está OK, hace el merge a staging.
2. Probar en el ambiente staging y luego mergear a main. Después del merge a staging, el CI/CD despliega automáticamente a un ambiente intermedio. El mentor lo prueba y te pide que tú también lo pruebes (porque tú conoces tu cambio mejor que nadie). Si ambos confirman que funciona, el mentor abre un MR de staging → main y lo aprueba. Ese segundo merge es el que va a producción.

Lo importante de este flujo: siempre hay un humano (el mentor DTI) revisando antes de que algo llegue a producción. No hay merges automáticos a main sin revisión.

7. CI/CD: qué pasa después del merge

Cuando el mentor DTI aprueba un merge —ya sea a staging o a main— GitLab dispara automáticamente un pipeline CI/CD. Es un robot que hace tres cosas seguidas, sin que nadie tenga que apretar botones:

1. Build & test: compila el proyecto y corre las pruebas.
2. Image: construye una imagen Docker (un paquete autocontenido con el sistema listo para instalarse en un servidor).
3. Deploy: actualiza el ambiente correspondiente con la nueva imagen.
   • Merge a staging → despliega al ambiente staging (interno, para validación).
   • Merge a main → despliega a producción (lo que usan las personas de la universidad).

Las ramas feature/* también disparan algunos jobs de validación (linter, tests, build de prueba), pero no despliegan a ningún ambiente. Eso te da feedback rápido en tu MR antes de que el mentor lo revise.

Lo mínimo que tienes que recordar

1. Saca tu rama feature/* desde staging (nunca desde main).
2. Trabaja en VSCode. Commit con prefijo (feat:, fix:, etc.). Push con el botón Sync.
3. Abre MR en gitlab.unach.cl con target staging y asigna a tu mentor DTI.
4. Espera review. Si te piden cambios, los haces, commit, push y se actualizan solos en el MR.
5. Cuando el mentor merge a staging, valida en el ambiente staging.
6. El mentor abre el MR de staging → main y, con tu OK, lo merge. Listo, está en producción.

Anexo: equivalente en terminal

Si prefieres terminal, esta es la traducción mínima de los pasos:

Versión presentación

Esta versión condensada está pensada para proyectarse en sala (kick-off de proyectos, inducción de practicantes). Usa las flechas o los controles para navegar; haz clic en Abrir presentación para verla a pantalla completa.

¿Te quedaron dudas? Habla con tu mentor DTI, escríbele en el canal del proyecto en GitLab, o asiste a la próxima sesión de inducción.