Trabajar con Git y GitLab en el DTI

# Trabajar con Git y GitLab en el DTI

### Flujo de trabajo para colaboradores

VSCode + `gitlab.unach.cl` + un mentor DTI

---

## ¿Qué es Git?

Es la herramienta que **guarda el historial** de todos los cambios de un proyecto.

- Evita que el equipo se pise mientras trabaja.
- Permite volver a versiones anteriores.
- Permite revisar el código **antes** de juntarlo con el resto.

> "Como Word con historial, pero en serio."

</div>
  <div>
    <img src="/articulos/git-workflow-con-gitlab/images/developer-monitors.jpg" alt="Persona programando en computador con varios monitores" class="slide-photo" />
  </div>
</div>

---

## ¿Qué es una rama?

Una **copia temporal** del proyecto donde haces tu trabajo **sin tocar al resto**.

Cuando está revisada, se "pega" de vuelta al proyecto principal.

> Como salir por una rama lateral del árbol, hacer tu cambio, y volver al tronco.

</div>
  <div>
    <img src="/articulos/git-workflow-con-gitlab/images/tree-branches.jpg" alt="Ramas de un árbol" class="slide-photo" />
  </div>
</div>

---

## Las tres ramas del DTI

- `main` — versión en **producción**.
- `staging` — versión **candidata**.
- `feature/*` — tu trabajo.

> **Regla de oro:** saca tu `feature/*` **desde `staging`**, nunca desde `main`.

---

## Git en VSCode

Todo se hace desde el panel **Source Control** (icono ⎇ a la izquierda):

1. Cambia a la rama `staging`.
2. Crea tu branch `feature/...`.
3. Edita, **Commit**, **Sync Changes**.

---

## Tu primer push: subir tu rama

Al hacer **Sync Changes**, tu rama aparece en `gitlab.unach.cl`.

Desde ahí cualquiera del equipo —incluido tu mentor DTI— puede verla.

---

## Abrir un Merge Request

1. En GitLab, ve a **Merge requests** → **+ New merge request**.
2. **Source:** tu rama `feature/...`. **Target:** `staging`.
3. **Reviewer:** tu **mentor DTI**.
4. Crea el MR. Listo.

---

## Review del mentor DTI

- El mentor revisa tu código y deja comentarios.
- Si pide cambios → ajustas, commit, push → se actualizan solos en el MR.
- Cuando aprueba → merge a `staging`.

---

## ¿Y después del merge?

GitLab arranca el **pipeline CI/CD** automáticamente:

`build → test → imagen Docker → deploy`

- Merge a `staging` → ambiente **staging**.
- Merge a `main` → **producción**.

---

## Lo mínimo que tienes que recordar

1. Saca tu `feature/*` **desde `staging`**.
2. Commit + Push desde VSCode.
3. MR a `staging` en GitLab. Reviewer = mentor DTI.
4. Cuando esté en staging, **tú validas también**.
5. El mentor merge a `main`. CI/CD despliega.

---

# ¿Dudas?

Habla con tu **mentor DTI**.

`gitlab.unach.cl` · `wiki-sistemas.unach.app`