Git methodology

Con el fin de trabajar de forma común con git, adopatmos una metodología de ramas
basada en la de Vincent Driessen.

In order to work in a git common way, we adopt a branching methodology based on Vincent
Driessen's model.

Ramas principales
El repositorio contiene tres ramas principales, estas ramas son larga vida, no se destruyen
y no reciben commits/pushes directos.

 master
 release
 develop

Paralelamente a la rama master, existen otras dos ramas llamadas develop

y release.

Consideramos origin/master como la rama principal donde el código fuente

de HEAD representa un estado production-ready (SIT).
Consideramos origin/release como la rama principal donde el código fuente
de HEAD representa un estado user-testing-ready (UAT).
Consideremos origin/develop como la rama principal donde el código fuente
de HEAD representa un estado con las últimas entregas de features o bugfixes. Hay un
sistema automático de despliegue en el entorno DEV.
Cuando el código de origin/develop alcanza un punto estable se integra
en origin/release.
Al finalizar un sprint el estado de origin/release contiene el estado el cual se integrará
en origin/master para su posterior despliegue en SIT.

Main branches
The repo holds three main branches, these branches are long-lived, they can't be removed
and it's strictly prohibited to do commit or to do push into them:

 master
 release
 develop

Parallel to the master branch, another two branches exist called develop and release.
We consider origin/master to be the main branch where the source code
of HEAD always reflects a production-ready state (SIT).
We consider origin/release to be the main branch where the source code
of HEAD always reflects a user-testing-ready state (UAT).
We consider origin/develop to be the main branch where the source code
of HEAD always reflects a state with the latest delivered development changes for the next
release. There is a CI system that deploys the HEAD state into DEV.
When the origin/develop code reaches a stable point we launch an integration
into origin/release.
origin/master is updated from origin/release when the current sprint get over. The
this state is deployed on SIT.

Ramas de soporte
Además de master, release and develop, nuestro modelo emplea dos tipos más de
ramas con el fin de facilitar el dasarrollo en paralelo entre los miembros del equipo. Al
contrario que las ramas principales, estas ramas tiene una vida limitada y son eliminadas
una vez ha llegado su fin.
Los diferentes tipos de ramas son:

 Ramas Features
 Ramas Bug-fixing

Suppoting branches
Next to the main branches master, release and develop, our development model uses
a two kind of supporting branches to aid parallel development between team members.
Unlike the main branches, these branches always have a limited life time, since they will be
removed eventually.
The different types of branches we may use are:

 Features branches
 Bugfixes branches

Ramas Features
Debe ser creada desde: develop
Debe integrarse en: develop
Convenio de nombre: features/group/branch_name
group puede ser: code_review, user_story, spike, improvement o layout, según el tipo de
tarea.
branch_name debe contener el códigoJIRA seguido de un nombre corto (formateado
en snake_case). Cuando agrupemos varias tareas JIRA en una misma rama, el código
JIRA es opcional.
features/user_story/HBO-1364_register_info

Las Feature branches son para desarrollar las nuevas características para la próximo
entraga del sprint. La esencia de una feature branch es que existe mientras el tarea esté
en desarrollo, eventualmente se puede intengrar en develop para testear los cambios en
el entorno DEV, también podemos desechar la rama por "exeprerimento fallido".

Ramas Bug-fixing
Debe ser creada desde: develop
Debe integrarse en: develop
Convenio de nombre: bugfixes/develop/branch_name
branch_name debe contener el códigoJIRA seguido de un nombre corto (formateado
en snake_case). Cuando agrupemos varias tareas JIRA en una misma rama, el código
JIRA es opcional.
bugfixes/develop/desings_bug

Las bug-fixing branches son para solventar fallos de las features cerras antes la próximo
entraga del sprint.

Features branches
May branch off from: develop
Must merge back into: develop
Branch naming convention: features/group/branch_name
group must be code_review, user_story, spike, improvement o layout, according to task
type.
branch_name must contains the JIRA code followed by a short name
(snake_case formated). When multiple JIRA task are grouped into a branch the JIRA code
is optional.
features/user_story/HBO-1364_register_info

Feature branches are used to develop new features for the next sprint delivery. The
essence of a feature branch is that it exists as long as the feature is in development.
Eventually can be merged back into develop (in order to test the feature on DEV
environment) or discarded (in case of a disappointing experiment).

Bug-fixing branches
May branch off from: develop
Must merge back into: develop
Branch naming convention: bugfixes/develop/branch_name
branch_name must contains the JIRA code followed by a short name
(snake_case formated). When multiple JIRA task are grouped into a branch the JIRA code
is optional.
bugfixes/develop/desings_bug

Bug-fixing branches are used to fix the bugs of the closed features before the next sprint
delivery.
Ciclo de vida
Las ramas de soporte están estrechamente relacionadas con las tareas de JIRA, por lo
cual, se establece para cada una de las transiciones entre los estados del ciclo de vida de
JIRA una o más acciones de git.

Lifecyle
In general, the supporting branches are strongly related to the JIRA tasks. We set one or
more git actions for each transition between JIRA workflow status.

Crear
Transición de TO DO a IN PROGRESS (Start Progress)
Al empezar una tarea crear una rama para trabajar la feature o el bug.

Actualizar
En el estado IN PROGRESS
Obterner los commits más recientes de develop en la rama actual. Si la rama es usada por
más de una persona, es recomendable realizar esta acción con frecuencia.

Integrar
Transición de IN PROGRESS a READY FOR QA (Ready for QA)
Enviar a la rama develop los commits de nuestra rama haciendo un "merge commit". Se
realiza cuando se quiere probar la feature/bug en el entorno de DEV.

Cerrar
Transición de READY FOR QA a PO CHECK (PO Check)
Actualizar, integrar y eliminar la rama de soporte.

Create
Transition from TO DO to IN PROGRESS (Start Progress)
When a task is started, we must create a (features/bugfixes) branch.

Update
On status IN PROGRESS
Get the most recent develop's commits into current branch. Perform this action when the
branch is shared between various people, it's best practice.

Integrate
Transition from IN PROGRESS to READY FOR QA (Ready for QA)
Send the commits of current branch to develop branch, using a "merge commit". Perform
this action when you want test the feature or bug on DEV environment.
Close
Transition from READY FOR QA to PO CHECK (PO Check)
Update, integrate and delete the supporting branch.