Reglas base sobre las ramas en git

Aunque cada equipo tiene una manera distinta de trabajar sus proyectos, existen ciertas reglas bases para poder llevar un proceso de control de versiones más organizado. Estas reglas son expuestas por Vincent Driessen en su artículo A successful Git branching model.

De manera resumida, las mas resaltantes son:

Ramas master y develop

El trabajo se organiza en dos ramas principales:

• Rama master: cualquier commit que pongamos en esta rama debe estar preparado para subir a producción
• Rama develop: rama en la que está el código que conformará la siguiente versión planificada del proyecto

Cada vez que se incorpora código a master, tenemos una nueva versión.

Además de estas dos ramas, Se proponen las siguientes ramas auxiliares:

• Feature
• Release
• Hotfix
  Cada tipo de rama, tiene sus propias reglas.

Feature or topic branches
Estas ramas se utilizan para desarrollar nuevas características de la aplicación que, una vez terminadas, se incorporan a la rama develop.

• Se originan a partir de la rama develop.
• Se incorporan siempre a la rama develop.
• Nombre: cualquiera que no sea master, develop, hotfix-* o release-*

Release branches
Estas ramas se utilizan para preparar el siguiente código en producción. En estas ramas se hacen los últimos ajustes y se corrigen los últimos bugs antes de pasar el código a producción incorporándolo a la rama master.

• Se originan a partir de la rama develop.
• Se incorporan a master y develop.
• Nombre: release-*.

Hotfix brancheshotfix branches

• Se origina a partir de la rama master
• Se incorporan a la master y develop
• Nombre: hotfix-*

Esas ramas se utilizan para corregir errores y bugs en el código en producción. Funcionan de forma parecida a las Releases Branches, siendo la principal diferencia que los hotfixes no se planifican.