|
@@ -12,9 +12,6 @@
|
|
|
## Introducción
|
|
## Introducción
|
|
|
Esta es una guía del modelo de ramificación utilizado en Mercados Eléctricos de Centroamérica.
|
|
Esta es una guía del modelo de ramificación utilizado en Mercados Eléctricos de Centroamérica.
|
|
|
|
|
|
|
|
-
|
|
|
|
|
-## Ramas Principales
|
|
|
|
|
-
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Ramas Principales
|
|
## Ramas Principales
|
|
@@ -61,7 +58,7 @@ 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`.
|
|
Cuando se inicie con una nueva característica, se creará una nueva rama a partir de `develop`.
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git checkout -b feature-myfeature develop
|
|
$ git checkout -b feature-myfeature develop
|
|
|
```
|
|
```
|
|
|
|
|
|
|
@@ -69,7 +66,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.
|
|
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.
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git checkout develop
|
|
$ git checkout develop
|
|
|
Switched to branch 'develop'
|
|
Switched to branch 'develop'
|
|
|
$ git merge --no-ff myfeature
|
|
$ git merge --no-ff myfeature
|
|
@@ -105,7 +102,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:
|
|
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:
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git checkout -b release-1.2 develop
|
|
$ git checkout -b release-1.2 develop
|
|
|
Switched to a new branch "release-1.2"
|
|
Switched to a new branch "release-1.2"
|
|
|
$ ./bump-version.sh 1.2
|
|
$ ./bump-version.sh 1.2
|
|
@@ -125,7 +122,7 @@ Cuando esta rama este lista para convertirse en un lanzamiento oficial, primero
|
|
|
|
|
|
|
|
Los primeros dos pasos se muestran a continuación:
|
|
Los primeros dos pasos se muestran a continuación:
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git checkout master
|
|
$ git checkout master
|
|
|
Switched to branch 'master'
|
|
Switched to branch 'master'
|
|
|
$ git merge --no-ff release-1.2
|
|
$ git merge --no-ff release-1.2
|
|
@@ -138,7 +135,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`.
|
|
Para mantener los cambios hechos en la rama `release`, necesitamos hacer un merge con `develop`.
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git checkout develop
|
|
$ git checkout develop
|
|
|
Switched to branch 'develop'
|
|
Switched to branch 'develop'
|
|
|
$ git merge --no-ff release-1.2
|
|
$ git merge --no-ff release-1.2
|
|
@@ -150,7 +147,7 @@ Este paso probablemente causara conflictos. Y eso sucede, se deben corregir y ha
|
|
|
|
|
|
|
|
Ahora se ha finalizado el trabajo en la rama `release` y esta puede ser eliminada, ya que no es necesaria.
|
|
Ahora se ha finalizado el trabajo en la rama `release` y esta puede ser eliminada, ya que no es necesaria.
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git branch -d release-1.2
|
|
$ git branch -d release-1.2
|
|
|
Deleted branch release-1.2 (was ff452fe).
|
|
Deleted branch release-1.2 (was ff452fe).
|
|
|
```
|
|
```
|
|
@@ -173,7 +170,7 @@ 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:
|
|
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:
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git checkout -b hotfix-1.2.1 master
|
|
$ git checkout -b hotfix-1.2.1 master
|
|
|
Switched to a new branch "hotfix-1.2.1"
|
|
Switched to a new branch "hotfix-1.2.1"
|
|
|
$ ./bump-version.sh 1.2.1
|
|
$ ./bump-version.sh 1.2.1
|
|
@@ -187,7 +184,7 @@ 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).
|
|
Luego de arreglar el fallo en la aplicación, se realiza el commit (puede ser un commit o varios).
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git commit -m "Fixed severe production problem"
|
|
$ git commit -m "Fixed severe production problem"
|
|
|
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
|
|
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
|
|
|
5 files changed, 32 insertions(+), 17 deletions(-)
|
|
5 files changed, 32 insertions(+), 17 deletions(-)
|
|
@@ -197,7 +194,7 @@ $ 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`.
|
|
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`.
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git checkout master
|
|
$ git checkout master
|
|
|
Switched to branch 'master'
|
|
Switched to branch 'master'
|
|
|
$ git merge --no-ff hotfix-1.2.1
|
|
$ git merge --no-ff hotfix-1.2.1
|
|
@@ -208,7 +205,7 @@ $ git tag -a 1.2.1
|
|
|
|
|
|
|
|
Luego, se debe incluir el cambio en `develop`:
|
|
Luego, se debe incluir el cambio en `develop`:
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git checkout develop
|
|
$ git checkout develop
|
|
|
Switched to branch 'develop'
|
|
Switched to branch 'develop'
|
|
|
$ git merge --no-ff hotfix-1.2.1
|
|
$ git merge --no-ff hotfix-1.2.1
|
|
@@ -223,7 +220,7 @@ Si el trabajo en `develop` requiere inmediatamente esta corrección de errores y
|
|
|
|
|
|
|
|
Finalmente, eliminamos la rama `hotfix`:
|
|
Finalmente, eliminamos la rama `hotfix`:
|
|
|
|
|
|
|
|
-```
|
|
|
|
|
|
|
+```shell
|
|
|
$ git branch -d hotfix-1.2.1
|
|
$ git branch -d hotfix-1.2.1
|
|
|
Deleted branch hotfix-1.2.1 (was abbe5d6).
|
|
Deleted branch hotfix-1.2.1 (was abbe5d6).
|
|
|
```
|
|
```
|
