Git workflow¶

Contenido¶

¿Qué es un workflow de Git?
Branches
Descripcion del flujo de trabajo
Esquema grafico del workflow
Posibles problemas

¿Qué es Git?¶

Git es un software de control de versiones, cuyo propósito es llevar registro de los cambios en archivos de computadora y coordinar el trabajo que varias personas realizan sobre archivos compartidos.

¿Qué es control de versiones?

¿Qué es Git?

¿Qué es un workflow de Git?¶

Es la definición de un flujo de trabajo en base a un modelo de branches. Asigna roles a diferentes tipos de branches y define cómo y cuándo tienen que ser usados. Utilizar un flujo de trabajo estandar nos permite: * Proporcionar un conjunto de reglas que facilita la implementación. * Asegurar un mínimo de fallas en lo que respecta al desarrollo u operaciones de desarrollo. * Organizar mejor el trabajo entre las distintas etapas del proceso de desarrollo (sprints, issues productivos, QA).

Estables¶

Un branch estable es aquel que persiste durante toda la duración del proyecto sobre el cual no se interactua directamente, sino a traves de branches temporales. Un repositorio tiene dos branches estables master y develop.

Master¶

Es el historial de releases. Cada merge a este branch debe ser una nueva versión del proyecto. Todo deploy a producción debe realizarse a partir de este branch.

Develop¶

Este branch nace de master y no se realiza trabajo directamente sobre el mismo. Es el branch al cual se deben integrar todos los cambios que se realicen en el proyecto y del cual se obtienen los cambios que formarán parte de una nueva versión.

Temporales¶

Un branch temporal es aquel donde se realiza el trabajo necesario para luego incorporarse a un branch estable a traves de un Pull Request.

Tipo Release¶

Nace de develop cuando se quieren integrar en una nueva versión productiva cambios como funcionalidades o bug fixes. Permite que se pueda seguir trabajando en develop mientras se cierra una nueva versión de la aplicacion. Si se necesita revision de QA antes de sacar la nueva versión, se realiza sobre este branch. En caso de que el proceso de QA detecte errores que necesiten ser corregidos, los cambios pueden ser realizados a partir de este branch y luego debera mergearse tanto a master como a develop.

Naming convention: release/x.y.z

Tipo Hotfix¶

Nace de master y es la única forma de introducirle cambios sin pasar primero por develop. Se utiliza para corregir algun bug que no fue detectado antes del release de la actual versión y que no puede esperar a la proxima debido a su importancia. Debe ser mergeado tanto a master como a develop y en caso de haber algún release en proceso, también al branch que le corresponda.

Naming convention: [id]-hotfix-[descripcion]

Tipo Feature¶

Nacen y son mergeados a develop. En este tipo de branch es donde se lleva a cabo el trabajo en situaciones normales. Esto incluye tareas como nuevas funcionalidades, corrección de bugs, refactors, etc. Dado que develop debe siempre ser un branch estable, todo trabajo que se quiera mergear al mismo debe estar terminado y ser sometido a una revisión de código. Así mismo, es responsabilidad del dev mantener dicha branch actualizada ante cada cambio en develop, particulamente en instancia de revisión.

Naming convention: [id]-[descripcion]
- id es un código que identifica la tarea en la herramienta de trackeo de tareas utilizada
- descripcion es una breve explicacion de la tarea a realizar en el branch, la cual puede coincidir con el titulo de la card o el issue que le corresponda

Descripcion del flujo de trabajo¶

En esta sección se comentara el flujo a seguir.

Setup¶

Se crea el repositorio con un branch master.
Se crea el branch develop a partir de master.

Feature nueva¶

Se crea un branch de tipo feature a partir de develop al comenzar el desarrollo de cada nueva funcionalidad.
Se trabaja sobre el branch creado, actualizando periódicamente si hay cambios en develop (git pull origin develop)
Una vez finalizado el trabajo, se crea un Pull Request a develop. Asegurandose que este al dia con develop y sea revisable
Si el Pull Request es aprobado, se mergea y el branch se borra.

Hotfix¶

Se crea un branch de tipo hotfix a partir de master.
Se trabaja sobre el branch creado intentando modificar lo justo y necesario para la correccion del bug.
Una vez finalizado el trabajo, se crean dos Pull Requests, uno a master y uno a develop.
- En caso de que sea necesario, tambien se crea un Pull Request a cada branch de release abierto.
Si los Pull Requests son aprobados, se mergean y el branch se borra.

Release nuevo¶

Se crea un branch de tipo release a partir de develop.
Se realizan retoques menores, como actualizacion de la documentacion y bumps de numeros de versiones.
Se realizan las pruebas de QA necesarias.
- En caso de encontrar algun error, se realizan las correcciones necesarias a partir de este branch.
Una vez finalizado el trabajo, se crean dos Pull Requests, uno a master y uno a develop.
Si los Pull Requests son aprobados, se mergean y el branch se borra.

Esquema grafico del workflow¶

Esquema general¶

Ejemplo¶

Posibles problemas¶

Feature de feature¶

Este problema consiste en una tarea "B" que depende de otra tarea "A", la cual se encuentra en desarrollo. * Si el desarrollo de "A" esta muy incompleto, se recomienda esperar hasta que "A" avance. * Si "A" ya contiene los cambios necesarios para desarrollar "B". * Se crea un branch de tipo feature a partir del branch de la tarea "A". * Se trabaja sobre el branch creado para "B". * Una vez finalizado, se espera a que "A" se mergee a develop. * Una vez que "A" esta mergeado, se crea el Pull Request para mergear "B".

Perdí la clave de 2FA en Gitlab¶

Si perdiste la app de autentificación, podés logearte alternativamente usando uno de los recovery codes que te dió Gitlab cuando activaste el 2FA.

Si también perdiste los recovery codes o los usaste todos pero tenés sincronizadas las keys de SSH en la pc, podés generar unos nuevos con el comando ssh git@gitlab.com 2fa_recovery_codes