git-workflow

Patrones de flujo de trabajo con Git

Mejores prácticas para el control de versiones con Git, estrategias de ramificación y desarrollo colaborativo.

Cuándo activarlo

• Configurar el flujo de trabajo de Git para un nuevo proyecto
• Decidir la estrategia de ramificación (GitFlow, trunk-based, GitHub flow)
• Redactar mensajes de commit y descripciones de PR
• Resolver conflictos de fusión
• Gestionar lanzamientos y etiquetas de versión
• Integrar a nuevos miembros del equipo en las prácticas de Git

Estrategias de ramificación

GitHub Flow (Simple, recomendado para la mayoría)

Ideal para despliegue continuo y equipos pequeños o medianos.

main (protegida, siempre desplegable)
  │
  ├── feature/user-auth      → PR → fusionar a main
  ├── feature/payment-flow   → PR → fusionar a main
  └── fix/login-bug          → PR → fusionar a main

Reglas:

• main siempre es desplegable
• Crear ramas de funcionalidad desde main
• Abrir una Pull Request cuando esté lista para revisión
• Después de la aprobación y de que pase la CI, fusionar a main
• Desplegar inmediatamente después de la fusión

Desarrollo basado en tronco (Equipos de alta velocidad)

Ideal para equipos con CI/CD sólido y feature flags.

main (tronco)
  │
  ├── rama de corta duración (máx. 1-2 días)
  ├── rama de corta duración
  └── rama de corta duración

Reglas:

• Todos hacen commit a main o a ramas de muy corta duración
• Los feature flags ocultan el trabajo incompleto
• La CI debe pasar antes de fusionar
• Desplegar varias veces al día

GitFlow (Complejo, basado en ciclos de lanzamiento)

Ideal para lanzamientos programados y proyectos empresariales.

main (lanzamientos de producción)
  │
  └── develop (rama de integración)
        │
        ├── feature/user-auth
        ├── feature/payment
        │
        ├── release/1.0.0    → fusionar a main y develop
        │
        └── hotfix/critical  → fusionar a main y develop

Reglas:

• main contiene solo código listo para producción
• develop es la rama de integración
• Las ramas de funcionalidad parten de develop y se fusionan de vuelta a develop
• Las ramas de lanzamiento parten de develop y se fusionan a main y develop
• Las ramas hotfix parten de main y se fusionan a main y develop

Cuándo usar cada una

Estrategia	Tamaño del equipo	Cadencia de lanzamientos	Ideal para
GitHub Flow	Cualquiera	Continuo	SaaS, aplicaciones web, startups
Trunk-Based	5+ con experiencia	Varias/día	Equipos de alta velocidad, feature flags
GitFlow	10+	Programado	Empresas, industrias reguladas

Mensajes de commit

Formato de Conventional Commits

<tipo>(<ámbito>): <asunto>

[cuerpo opcional]

[pie(s) opcional(es)]

Tipos

Tipo	Uso	Ejemplo
feat	Nueva funcionalidad	feat(auth): add OAuth2 login
fix	Corrección de errores	fix(api): handle null response in user endpoint
docs	Documentación	docs(readme): update installation instructions
style	Formato, sin cambio de código	style: fix indentation in login component
refactor	Refactorización de código	refactor(db): extract connection pool to module
test	Agregar/actualizar pruebas	test(auth): add unit tests for token validation
chore	Tareas de mantenimiento	chore(deps): update dependencies
perf	Mejora de rendimiento	perf(query): add index to users table
ci	Cambios en CI/CD	ci: add PostgreSQL service to test workflow
revert	Revertir un commit anterior	`revert: revert