Modelo de branching
Este estándar define el Git flow que siguen los repositorios y aplicaciones de Crehana. Aplica a todos los equipos.
El control de versiones da visibilidad de cada cambio que se hace en la aplicación y permite revertirlo cuando hace falta. Git registra el historial de cambios y ayuda a combinar el trabajo de varias personas, así el equipo trabaja en distintas partes de la aplicación al mismo tiempo.
El flujo de un vistazo
Una feature branch sale de main, el equipo de QA la valida y el cambio llega a main, que siempre representa producción.
Feature branches
- Toda feature branch sale de
main(omaster, según el repo). - Cada feature branch corresponde a una task de Jira.
- Una task representa idealmente 1 día de trabajo y como máximo 3. En ningún caso puede durar más de un sprint.
- Toda feature branch pasa por QA para que el equipo de QA la valide.
Branches de QA
El equipo de QA valida cada feature branch antes de que llegue a producción. Ten en cuenta:
- Toda feature branch pasa por QA, sin excepciones.
- Las branches de QA se resetean cuando los conflictos lo hacen necesario.
Hotfix
Un hotfix es una solución urgente a un problema en producción, sobre todo cuando bloquea la operación de los clientes.
- No crees branches de hotfix para tareas programadas del sprint que no son urgentes.
- Todo push a
main(omaster) se replica en las branches de QA.
Main
El código de main (o master) es el código del entorno de producción. Todo lo que se sube ahí representa lo que corre en producción.
Relacionado
- Branches y commits — cómo nombrar branches y escribir mensajes de commit