Este documento describe los pasos para gestionar repositorios de código usando ramas y pull requests. Las características se desarrollan en ramas separadas y se fusionan a la rama master mediante pull requests. Las versiones se lanzan a partir de ramas de liberación estabilizadas y se etiquetan. Los arreglos de errores se realizan en ramas de corrección con origen en la etiqueta correspondiente.

1. master
features/feature2
features/feature1 features/feature3 features/feature4
releases/v1.0.0
hotfixes/v1.0.1
v1.0.0 v1.0.1
hotfixes/v1.0.2
v1.0.2
Gestión de repositorios en pocas palabras
Todas las ramas se integran en la
master vía pull request, tras lo cual se
comprueba que no se ha roto nada (y,
si algo comienza a fallar, se arregla).
Una rama de release se
genera a partir del master, y
en ella se estabiliza el código
que va a ser publicado.
Se generará una tag por
cada una de las versiones
de código que se pretendan
publicar.
Cuando se detecte un error
en producción, se generará
una rama con origen la tag
de la versión afectada y
que, una vez solucionada,
generará una nueva tag.
Cada nueva feature que se
quiera desarrollar requerirá
de una rama específica,
creada a partir de master.
No se hacen integraciones en la rama
master si no está estable.
Cuando una funcionalidad
haya alcanzado un hito, se
puede realizar un merge
parcial de la rama en master.
Si se necesita una funcionalidad nueva
que se ha integrado en master tras la
creación de la rama de la feature, se
puede realizar un merge de master
para disponer del código fuente.
Feature: mejora o nueva
funcionalidad de la aplicación.
Release: estabilización previa a
la publicación de la aplicación.
Hotfix: solución a un error
detectado en producción.