9. Flujo de Desarrollo con Git Flow
El modelo Git Flow permite gestionar el ciclo de vida del desarrollo de software mediante una estructura de ramas bien definida. Es ideal para entornos colaborativos, como los equipos Android de Alpura, donde se requiere estabilidad, trazabilidad y agilidad.
9.1 Ramas principales
| Rama | Propósito |
|---|---|
main | Código en producción |
develop | Última versión lista para pruebas de QA |
9.2 Ramas de soporte
| Rama | Convención | Propósito |
|---|---|---|
feature/ | feature/nombre-cambio | Nuevas funcionalidades |
bugfix/ | bugfix/descripcion | Corrección de errores detectados en QA |
release/ | release/vX.Y.Z | Preparación de versión de producción |
hotfix/ | hotfix/correccion-critica | Fix urgente desde producción (main) |
9.3 Flujo Git Flow completo
9.4 Revisión de Pull Requests
Todo cambio debe ser incorporado a través de un Pull Request (PR) siguiendo estas reglas:
- CI debe pasar correctamente
- Revisado por al menos 1 desarrollador y 1 líder técnico
- Aprobación automática por bot (ej. SonarCloud)
- Descripción clara del cambio y ticket asociado
9.5 Políticas de aceptación de cambios
- No se permiten merges sin revisión
- No se permite push directo a
mainodevelop - PRs deben incluir descripción funcional y técnica
- Documentar decisiones arquitectónicas cuando aplique
- Validación QA antes de promover a producción
9.6 Automatización en Pull Requests
- Validaciones automáticas: build, lint, test, coverage
- Uso de etiquetas (labels):
feature,bug,hotfix,security,refactor - Generación automática de changelogs con Conventional Commits
9.7 Herramientas complementarias
- GitHub Actions, GitLab CI, Bitrise para automatización
- SonarCloud para análisis de calidad en PRs
- Husky para hooks pre-commit (
lint-staged,ktlint) - Danger para revisión automática de convenciones en PR
Este flujo permite al equipo mantener una cadencia de entregas ágil, organizada y segura, incluso trabajando múltiples personas simultáneamente en funcionalidades paralelas.