Saltar a contenido

Flujo Git recomendado

Una forma simple y efectiva es Trunk-based + Pull Requests: una rama principal estable y ramas cortas por tarea.

Resumen del manejo de GIT

Estructura mínima de ramas

  • main: siempre estable. Es lo que corre en el único ambiente (o lo que se evalúa).
  • feature/<tema>-<id>: ramas cortas por tarea.
    Ej: feature/login-12, feature/ui-header-07
  • (Opcional) fix/<bug>: correcciones rápidas.
    Ej: fix/nullpointer-21

Regla clave: nadie hace push directo a main.

Ciclo de trabajo (paso a paso)

  1. Mantener main como rama por defecto.
  2. Tomar una tarea (issue) y crear rama desde main:
  3. git checkout main
  4. git pull
  5. git checkout -b feature/<algo>
  6. Trabajar y hacer commits pequeños y claros.
  7. Publicar la rama:
  8. git push -u origin feature/<algo>
  9. Abrir Pull Request (PR) hacia main.
  10. Revisión obligatoria:
  11. opcional 1 aprobación (ideal 2 si pueden)
  12. El PR debe pasar validaciones básicas:
  13. compila / corre
  14. no rompe pruebas (si existen)
  15. Hacer merge (recomendado: Squash & Merge para historial limpio).

Convención simple de commits (fácil de evaluar)

Usar prefijos:

  • feat: ... (funcionalidad nueva)
  • fix: ... (bug)
  • docs: ... (documentación)
  • refactor: ... (mejoras internas sin cambiar comportamiento)

Ejemplos: - feat: login con jwt - fix: corrige validación email - docs: actualiza README - refactor: separa servicio de persistencia

4) Manejo del único ambiente

Como solo hay un ambiente, main debe estar siempre “verde”:

  • todo entra por PR
  • no se mergea código que no compile o no corra
  • si main se rompe, la prioridad #1 es arreglarlo (rama fix/...)

Organización del equipo (6 personas)

  • 1 persona “dueña” de main (coordina merges, no manda).
  • Rotar roles por semana:
  • Merge manager: organiza PRs y merges
  • QA reviewer: valida que corra/compile antes del merge

Política recomendada: - PR pequeño > PR gigante - máximo 1–2 PR grandes por persona por semana

Reglas simples para evitar el caos

  • No mezclar varias tareas en una misma rama.
  • Mantener ramas cortas (1 tarea = 1 rama = 1 PR).
  • Actualizar tu rama antes de pedir merge (para evitar conflictos):

Opción A (simple, con merge)

  • git fetch origin
  • git merge origin/main

Opción B (más limpia, con rebase)

  • git fetch origin
  • git rebase origin/main