Flujo Git

En Plataforma, usamos GitLab como repositorio de código y GitFlow como metodología o flujo de trabajo, siguiendo el siguiente esquema de ramas:

  • master: Rama estable de código, a partir de esta rama se generan las ramas de releases estables dentro del quarter.

  • develop: Rama de nuevas funcionalidades programadas dentro del Q, de acuerdo al roadmap de producto. Esta rama se mergea finalizado el Q a master una vez estabilizada y probada.

  • stable (release candidate): Rama generada a partir de master, destinada a la corrección de bugs y mejoras, esta rama se despliega semanalmente en el entorno estable y se mergea tanto a master como a develop.

Cada funcionalidad nueva, corrección de un bug o mejora lleva asociada la correspondiente Issue en GitLab etiquetada como FEATURE, BUG o UPTURN.

La issue lleva asociada una rama de desarrollo y una breve descripción:

Además la issue debe ir asociado al milestone correspondiente (semanal si es una release candidate o RC) o trimestral si está destinada al cierre del Q.

Una vez terminado el desarrollo se genera una pull request o petición para mergear la rama a develop o la rama stable, para ello desde GitLab se crea la correspondiente petición.

Marcaremos el check de borrar la rama origen una vez mergeada:

y se asigna a un miembro del equipo, por normal general más senior.

Una vez probada y validada la issue en el entorno correspondiente, esta debe pasar a estado cerrado: