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: