Add pdf and full image

README.md

@@ -1,6 +1,7 @@
 # Git Branching Model
 ## Introducción
 
+![git branching model](./img/git-branching-model-full.png)
 ## El repositorio central
 
 ## Ramas Principales
@@ -64,7 +65,6 @@ Updating ea1b82a..05e9557
 $ git branch -d myfeature
 Deleted branch myfeature (was 05e9557).
 $ git push origin develop
-
 ```
 
 El flag `--no-ff` hace que el merge cree un nuevo commit, incluso si el merge se puede realizar con un fast-forward. Esto evita perder información sobre la historia de commits de una rama `feature` y agrupa todos los commits que añadieron la característica.
@@ -142,6 +142,80 @@ $ git branch -d release-1.2
 Deleted branch release-1.2 (was ff452fe).
 ```
 
+### Ramas `hotfix`
+
+Pueden ramificarse de: `master`
+
+Deben hacer merge con: `develop` y `master`
+
+Nombre: debe iniciar con `hotfix-*` no puede ser llamada `master, develop, feature-*` o `release-*`
+
+Las ramas `hotfix` son muy similares a las ramas `release`, en el sentido que también estan pensadas para preparar un nuevo lanzamiento de producción, aunque no esté planificado. Surgen de la necesidad de acturar inmediateamente sobre el estado no deseado de una versión de producción en vivo. Cuando un fallo crítico en una versión de producción debe resolverse inmediatamente, una rama `hotfix` puede separarse de la etiqueta correspondiente en `master`que marca la versión de producción.
+
+La escencia es que el trabajo de los miebros del equipo, en la rama `develop` puede continuar, mientras que otra persona está preprando una solución rápida de producción.
+
+**Creación de una rama `hotfix`**
+
+Las ramas `hotfix`son creadas a partir de `master`. For ejemplo, digamos que la versión actual de producción es la 1.2 y está teniendo problemas por un bug. Pero los cambios en la rama `develop` son inestables. Entonces debemos crear una nueva rama `hotfix`y solucionar el problema:
+
+```bash
+$ git checkout -b hotfix-1.2.1 master
+Switched to a new branch "hotfix-1.2.1"
+$ ./bump-version.sh 1.2.1
+Files modified successfully, version bumped to 1.2.1.
+$ git commit -a -m "Bumped version number to 1.2.1"
+[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
+1 files changed, 1 insertions(+), 1 deletions(-)
+```
+
+No se nos debe olvidar incrementar el número de versión despues de crear la nueva rama.
+
+Luego de arreglar el fallo en la aplicación, se realiza el commit (puede ser un commit o varios).
+
+```bash
+$ git commit -m "Fixed severe production problem"
+[hotfix-1.2.1 abbe5d6] Fixed severe production problem
+5 files changed, 32 insertions(+), 17 deletions(-)
+```
+
+**Finalizando una rama `hotfix`**
+
+Al finalar de corregir el fallo, la rama `hotfix` se debe unir nuevamente a `master`, pero tambien debe de ser unida a `develop`, con el objeto de asegurar que la corrección del fallo esté incluido en el próximo lanzamiento. Este proceso es exactament igual que el realizado con las ramas `release`.
+
+```
+$ git checkout master
+Switched to branch 'master'
+$ git merge --no-ff hotfix-1.2.1
+Merge made by recursive.
+(Summary of changes)
+$ git tag -a 1.2.1
+```
+
+Luego, se debe incluir el cambio en `develop`:
+
+```
+$ git checkout develop
+Switched to branch 'develop'
+$ git merge --no-ff hotfix-1.2.1
+Merge made by recursive.
+(Summary of changes)
+```
+La única excepción a la regla es que, **cuando una rama `release` existe actualmente, los cambios de `hotfix` necesitan ser fusionados en esa rama `release`, en lugar de `develop`.**
+
+Volver a unir la corrección de fallos en la rama `release` resultará finalmente en que la corrección de fallos se fusione también en `develop`, cuando la rama `release` esté terminada.
+
+Si el trabajo en `develop` requiere inmediatamente esta corrección de errores y no puede esperar a que la rama de la versión esté terminada, puede fusionar con seguridad la corrección de errores en `develop`.
+
+Finalmente, eliminamos la rama `hotfix`:
+
+```
+$ git branch -d hotfix-1.2.1
+Deleted branch hotfix-1.2.1 (was abbe5d6).
+```
+
+
+
+