|
|
@@ -69,7 +69,7 @@ $ git checkout -b feature-myfeature develop
|
|
|
|
|
|
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
|
|
|
Switched to branch 'develop'
|
|
|
$ git merge --no-ff myfeature
|
|
|
@@ -105,7 +105,7 @@ Es exactamente al comienzo de una rama `release`que se le asigna un número de v
|
|
|
|
|
|
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
|
|
|
@@ -125,7 +125,7 @@ Cuando esta rama este lista para convertirse en un lanzamiento oficial, primero
|
|
|
|
|
|
Los primeros dos pasos se muestran a continuación:
|
|
|
|
|
|
-```bash
|
|
|
+```
|
|
|
$ git checkout master
|
|
|
Switched to branch 'master'
|
|
|
$ git merge --no-ff release-1.2
|
|
|
@@ -138,7 +138,7 @@ 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
|
|
|
@@ -174,7 +174,6 @@ La escencia es que el trabajo de los miebros del equipo, en la rama `develop` pu
|
|
|
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
|
|
|
@@ -189,7 +188,6 @@ No se nos debe olvidar incrementar el número de versión despues de crear la nu
|
|
|
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(-)
|
|
|
@@ -200,7 +198,6 @@ $ git commit -m "Fixed severe production problem"
|
|
|
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`.
|
|
|
|
|
|
```
|
|
|
-:::bash
|
|
|
$ git checkout master
|
|
|
Switched to branch 'master'
|
|
|
$ git merge --no-ff hotfix-1.2.1
|
|
|
@@ -212,7 +209,6 @@ $ git tag -a 1.2.1
|
|
|
Luego, se debe incluir el cambio en `develop`:
|
|
|
|
|
|
```
|
|
|
-:::bash
|
|
|
$ git checkout develop
|
|
|
Switched to branch 'develop'
|
|
|
$ git merge --no-ff hotfix-1.2.1
|
|
|
@@ -228,7 +224,6 @@ Si el trabajo en `develop` requiere inmediatamente esta corrección de errores y
|
|
|
Finalmente, eliminamos la rama `hotfix`:
|
|
|
|
|
|
```
|
|
|
-:::sh
|
|
|
$ git branch -d hotfix-1.2.1
|
|
|
Deleted branch hotfix-1.2.1 (was abbe5d6).
|
|
|
```
|
