Skip to main content

🛠️ Alpura - Estrategia de branching

A continuación se explica ¿que es git flow? y cual sería la estrategia de branching-name, a la hora de crear una rama de trabajo.

🧠 ¿Qué es Git Flow?​

Git Flow es una estrategia de branching que estandariza el ciclo de vida de desarrollo y despliegue en proyectos con versiones periódicas.
Se basa en cinco tipos de ramas principales:

  • main (o master): siempre refleja el código en producción, y cada release se etiqueta aquí.
  • development: rama de integración donde confluyen todas las funcionalidades antes de preparar un release.
  • feature/*: ramas creadas desde main o development y son ramas de trabajo para nuevas funcionalidades.
  • release/*: ramas creadas desde development para pruebas finales, ajustes de versionado y documentación.
  • hotfix/*: ramas creadas desde main o development para correcciones urgentes en producción.

⚙️ Sintaxis de nombres de ramas​

<prefijo>/<ID-tarea>-<descripción-breve>
  • <prefijo>: tipo de rama (feature, bugfix, hotfix, etc.)
  • <ID-tarea>: opcional, el identificador de la tarea o ticket en tu gestor (JIRA, Trello…)
  • <descripción-breve>: una frase corta en minúsculas y sin espacios, usando guiones para separar palabras (add-users, integrate-api-user, dynamic-dashboard, etc.)

🚀 Prefijos recomendados​

  • feature/

Ramas para implementar nuevas funcionalidades o historias de usuario.

Cuando usar: cada vez que empieces a desarrollar un workflow completo o un módulo nuevo.

  • bugfix/ (o fix/)

Para corregir errores que no son críticos en producción.

Cuando usar: cuando encuentras un fallo en develop o en una rama de release.

  • hotfix/

Para arreglos urgentes directamente sobre main en producción.

Cuando usar: para corregir errores críticos que están afectando a usuarios en vivo.

  • release/

Para preparar un nuevo lanzamiento: ajustes menores, versionado y documentación.

Cuando usar: cuando develop está listo para generar un paquete de release.

  • chore/

Tareas de mantenimiento que no afectan la funcionalidad de usuario (actualizar dependencias, limpieza de código, configuraciones).

Cuando usar: cambios internos, configuración de CI/CD, actualizaciones de librerías.

  • docs/

Para actualizaciones de documentación (README, CHANGELOG, wikis).

Cuando usar: cuando agregas o corriges guías, tutoriales o comentarios de documentación.

  • test/

Para añadir o ajustar pruebas unitarias, de integración o end-to-end.

Cuando usar: al escribir nuevos casos de test o refactorizar suites de testing.

  • refactor/

Cambios de estructura o limpieza de código sin añadir funcionalidades ni arreglar bugs.

Cuando usar: reorganizar módulos, renombrar componentes o mejorar la legibilidad.

✨ Ejemplos:

feature/api-implementation-charts
feature/PROY-123-login-form
bugfix/456-nullpointer-exception
release/1.2.0
hotfix/1.2.1
chore/update-dependencies
warning

Toda la estructrura del branching-name debera estar en ingles.

En caso contrario no sera aceptado por la área de arquitectura y no podra ser mergeado dicha rama.