Flujo de Trabajo con GitHub
Guía visual de ramas, pull requests y despliegues en el equipo de desarrollo
Ramas y Entornos
main → PRO Producción · Merge el día hábil anterior al despliegue
pre → PRE QA · Punto de validación funcional entre devs y QA
feature/* · fix/* → DEV Desarrollo · Validación propia antes del code review
Flujo de Ramas
Nomenclatura de Ramas
feature/MBN-XXXX-descripcion
Para nuevas funcionalidades
fix/MBN-XXXX-descripcion
Para correcciones detectadas en QA
Las ramas deben vivir máximo 1 semana. Si dura más, la tarea es demasiado grande.
Microservicios: cada repositorio tiene sus propias ramas
main y pre independientes. Siempre crea tu rama desde main actualizado. Haz
git pull origin main antes.
Pull Requests
feature/* → pre Flujo normal: nueva funcionalidad lista para QA
fix/* → feature/* Corrección de QA encapsulada en su propia rama
feature/* → main El día hábil anterior a la fecha de despliegue confirmada
Requiere 2 aprobaciones
Mid / Senior — calidad, diseño e impacto
Junior — legibilidad y aprendizaje
Principios Clave
Trunk-based development
Todo sale de
main y vuelve a main. Sin branches de larga duración.Commits pequeños y frecuentes
Cada commit = un cambio lógico. Haz push regularmente para no perder trabajo.
No merge a main sin fecha
main solo recibe código que va a desplegarse, y el merge se hace el día hábil anterior al despliegue. Sin desarrollos huérfanos en producción.Historial limpio y trazable
Cada fix en su rama. Conventional commits. El historial es documentación.
Flujo de Corrección — QA detecta un error
QA detecta error
en PRE
→
fix/MBN-XXXX-fix
desde feature/*
→
PR + 2 aprobaciones
fix → feature/*
→
Merge feature → pre
re-despliegue en PRE
→
QA re-valida
en PRE
! Nunca modifiques directamente la rama
feature/ original. Cada corrección en su propia rama fix/ mantiene el historial limpio y permite rastrear exactamente qué se cambió y por qué. Conventional Commits
feat:Nueva funcionalidad
fix:Corrección de bug
docs:Documentación
refactor:Mejora interna
test:Tests
chore:Mantenimiento
Ejemplo: feat(MBN-1234): add user validation endpoint