Release Branch

README.md

@@ -35,7 +35,7 @@ Pueden ramificarse de: `develop`
 
 Deben hacer merge con: `develop`
 
-Nombre: debe iniciar con `feature_*` no puede ser llamada `master, develop, release_*` o `hotfix_*`
+Nombre: debe iniciar con `feature-*` no puede ser llamada `master, develop, release-*` o `hotfix_*`
 
 Estas ramas se utilizan para desarrollar nuevas características para la próxima versión o para una futura versión. Al iniciar el desarrollo de una característica, la versión de destino en la que se incorporará esta característica puede ser descnocida en ese momento. La escencia de una rama `feature` es que existe mientras la característica esta en desarrollo, pero eventualmente se fusionará de nuevo con `develop` (para añadir definitivamente la característica al próximo lanzamiento) o se descartará (en caso de un experimento fallido).
 
@@ -48,20 +48,21 @@ Las ramas `feature`suelen existir sólo en los repos de desarrolladores, no en `
 Cuando se inicie con una nueva característica, se creará una nueva rama a partir de `develop`.
 
 ```
-$ git checkout -b feature_myfeature develop
+$ git checkout -b feature-myfeature develop
 ```
 
 **Merge de una rama `feature`**
 
 Una vez finalizado el desarrollo de una nueva característica, se debe hacer un merge a `develop` para incorporar los cambios en un lanzamiento posterior.
 
-```
+```bash
 $ git checkout develop
-
-$ git merge --no-ff feature_myfeature
-
-$ git branch -d feature_myfeature
-
+Switched to branch 'develop'
+$ git merge --no-ff myfeature
+Updating ea1b82a..05e9557
+(Summary of changes)
+$ git branch -d myfeature
+Deleted branch myfeature (was 05e9557).
 $ git push origin develop
 
 ```
@@ -72,6 +73,74 @@ El flag `--no-ff` hace que el merge cree un nuevo commit, incluso si el merge se
 
 En el segundo caso (plain), es imposible observar desde el hisotrial Git cuales commits han implementado la característica, tendríamos que leer los mensajes de log. Revertir una `feature`completa es muy dificil en esta situación, sin embargo es mas facil si se utiliza el flag `--no-ff`.
 
+### Ramas `release`
+
+Pueden ramificarse de: `develop`
+
+Deben hacer merge con: `develop` o `master`
+
+Nombre: debe iniciar con `release-*` no puede ser llamada `master, develop, feature-*` o `hotfix_*`
+
+Las ramas `release` son de ayuda para la preparación del lanzamiento de una nueva versión de producción. Permiten la correción de errores menores y la preparación de metadatos para una versión (número de versión, fechas de compilación, etc.). Al hacer todo este trabajo en una rama `release`, la rama de desarrollo se libera para recibir nuevas características para una versión posterior.
+
+El momento clave para separarse a una nueva rama `release` es cuando `develop`(casi) refleja el estado deseado de la nueva versión. Por lo menos todas las características que están dirigidas a la versión que se va a lanzar deben fusionarse a `develop` en este momento. Todas las características destinadas a futuras versiones deben de esperar hasta que la rama `release`se haya separado.
+
+Es exactamente al comienzo de una rama `release`que se le asigna un número de versión para el próximo lanzamiento, no antes. Hasta ese momento, `develop` reflejaba los cambios para la "proxima versión", pero no esta claro cuando la esa "proxima versión" se convertirá en 0.3 o 1.0, por ejemplo,  hasta que se inicia la rama `release`. Esta decisión se toma al inicio de cada rama `release` y se lleva a cabo mediante las reglas del proyecto sobre el número de versión.
+
+
+**Creación de una rama `release`**
+
+Las ramas `release` son creadas a partir de `develop`. Por ejemplo, si la versión en producción vigente es 1.1.5 y tenemos un nuevo lanzamiento con cambios grandes. El estado de `develop` esta listo para la "proxima versión" y hemos decidido que será la versión 1.2 (en vez de 1.1.6 o 2.0). Entonces, creamos una nueva rama con un nombre que refleje el número de la versión nueva:
+
+```bash
+$ git checkout -b release-1.2 develop
+Switched to a new branch "release-1.2"
+$ ./bump-version.sh 1.2
+Files modified successfully, version bumped to 1.2.
+$ git commit -a -m "Bumped version number to 1.2"
+[release-1.2 74d9424] Bumped version number to 1.2
+1 files changed, 1 insertions(+), 1 deletions(-)
+```
+
+Depues de crear la nueva rama, incrementamos el número de versión. En el ejemplo, `bump-version.sh` es un script ficticio que cambia algunos archivos en la copia para reflejar la nueva versión. (Por supuesto este cambio puede ser manual, el punto es que algunos archivos han cambiado.) Luego, se realiza un commit con los cambios y la nueva versión.
+
+Esta nueva rama puede existir por algún tiempo, hasta que el lanzamiento sea realizado. Durante este tiempo, se pueden realizar correción de errores pequeños. Añadir nuevas características a esta rama esta estrictamente prohibido. Si es necesario, estos deben ser unidos primero a `develop` y esperar por un nuevo release.
+
+**Finalizando una rama `release`**
+
+Cuando esta rama este lista para convertirse en un lanzamiento oficial, primero se deben realizar algunas tareas. Primero, la rama `release` debe unirse a `master` (dado que cada commit en `master` es un nuevo lanzamiento por definición). Luego, ese commit en `master` debe ser tageado para referencias futuras. Finalmente, los cambios realizados en la rama `release` deben ser unidos con `develop`, para que los futuros releases tambien incorporen la correción de errores.
+
+Los primeros dos pasos se muestran a continuación:
+
+```bash
+$ git checkout master
+Switched to branch 'master'
+$ git merge --no-ff release-1.2
+Merge made by recursive.
+(Summary of changes)
+$ git tag -a 1.2
+```
+
+El lanzamiento se ha realizado, y ha sido tageado para futuras referencias.
+
+Para mantener los cambios hechos en la rama `release`, necesitamos hacer un merge con `develop`.
+
+```bash
+$ git checkout develop
+Switched to branch 'develop'
+$ git merge --no-ff release-1.2
+Merge made by recursive.
+(Summary of changes)
+```
+
+Este paso probablemente causara conflictos. Y eso sucede, se deben corregir y hacer el commit corresondiente.
+
+Ahora se ha finalizado el trabajo en la rama `release` y esta puede ser eliminada, ya que no es necesaria.
+
+```
+$ git branch -d release-1.2
+Deleted branch release-1.2 (was ff452fe).
+```