Si estás involucrado con términos como git, Github, línea de comandos, release y branches se te son familiares, este tutorial de git flow es para ti ya que hablaremos de como hacer que tu y tu equipo de desarrollo sea más productivo.
Si necesitas expertos en git flow vista nuestra página de desarrollo a la medida, podemos ayududarte.
Introducción
A pesar de trabajar en una empresa de Marketing Digital, de vez en cuando es necesario hacer desarrollos y trabajar en equipos de programadores para generar productos que apoyen nuestras campañas digitales.
En estos casos tenemos que usar herramientas como editores de texto, servidores de desarrollo y staging y sobre todo herramientas de versionado.
No se puede negar que git es la herramienta de versionado que ganó la competencia debido a su flexibilidad, versatilidad y capacidad de adaptarse a los requerimientos más exigentes de los equipos de desarrollo.
Esta versatilidad genera una nueva necesidad: Cómo hago para generar una flujo de trabajo unificado que permita adicionar en nuevas funcionalidades, manejar etapas de staging y finalmente pasar a producción. La respuesta es Gitflow.
Este post está basado en el artículo A successful Git branching model de Vincent Driessen
Qué es git flow
Se podría pensar en Git-flow como una serie de macros que se aseguran que uses branches y tags con convenciones iguales, a través del desarrollo de tu producto y así siempre saber en qué estado está tu proyecto, cómo saber si una rama es para algo nuevo o un arreglo y finalmente,, facilitar el paso de desarrollo a producción.
Es importante anotar que todo lo que se hace con git-flow se puede lograr con comandos de git puros, pero git-flow nos asegura que se ejecuten todos los pasos, que se usen los branches correctos y etiquetar cuando se debe hacer.
De manera gráfica el flujo que propone git-flow es el siguiente:
La descripción de esta gráfica es la siguiente
- Se tienen por defecto tres branches: master, release y develop Siendo develop la rama o branch donde ocurre todo y master, la branch de producción.
- A partir de develop, se crean nuevas ramas con el prefijo feature para la creación de nueva funcionalidad y arreglo de errores que no tienen urgencia.
- En cualquier momento se debe poder pasar de develop a master, lo que quiere decir que no se debe desarrollar en develop si no en las branches que empiezan con feauture
- Para pasar de develop a master se debe usar una branch intermedia llamada release. Esta branch se usa como un punto intermedio en la cual solo se pueden corregir errores que puedan surgir antes de pasar a master.
- Si al pasar a master se descubre un error, se usan branches con prefijo hotfix para corregir errores de producción.
- Cada vez que se pasa a master, se debe crear una etiqueta con el nombre del release.
Inicio de git-flow
Todo inicia con git flow init
Como se puede ver, git-flow crea todas las branches necesarias
Aquí se pueden subir las nuevas ramas al servidor remoto.
Creación de una nueva funcionalidad o corrección de un error
Para git-flow esto es un nuevo feature, es decir, hay que ejecutar
git flow feature start…
Como se puede ver git-flow creó una nueva rama llamada feature/1234-7890-un-cambio-pequeno e hizo un checkout a esta rama automáticamente
Sobre los nombres de los branches
Se recomienda que al trabajar con git-flow los branches sigan una convención de nombres que esté fuertemente ligada con el bug traker ya sea Jira, The Bug Genie, etc.
IdDelBug-NumeroDeComentario-DescripciónDeLaFuncionalidad
En el ejemplo anterior tenemos
- Id del bug: 1234
- Número del comentario: 7890. Se asume que en un comentario del bug es en el que se define que hay que hacer en el código
- Descripción de la funcionalidad: Idealmente se separa por guiones. Algo como nuevo-comando-de-reset
**Una vez creada la rama con el nuevo feature, se puede trabajar como se hace normalmente con git **
Publicando la nueva rama (Colaboración)
Git ayuda a trabajo colaborativo, así que es necesario publicar esta nueva rama al servidor. Esto se logra con git flow feature publish <feature>
Nota: este comando toma su tiempo ya que envía también los cambios al servidor remoto
Otros colaboradores
Estando el código en el servidor gracias a git flow feature publish <feature>, el resto de desarrolladores ya pueden tajar en la nueva funcionalidad. Para esto lo que debe hacer es usar git normalmente para descargar y sincronizar el código:
git fetch
git checkout feature/1234-7890-un-pequeno-cambio
…. (cambios a los archivos)
git fetch #(se trae cambio remotos)
git rebase origin feature/1234-7890-un-pequeno-cambio
… (mas cambios)
git push
Finalización del feature
Cuando se termine de crear la nueva funcionalidad, Se debe ejecutar git flow feature finish <feature> y así pasar nuevamente a la rama develop
Lo que hace este comando es
- Hacer merge con develop
- Borrar la rama feature en la que estábamos trabajando
- No regresa a la rama develop
Como se puede ver, aquí ya se puede hacer push al servidor
Limpieza
Con el feature finalizado, esta rama ya no es necesaria, entonces lo mejor es borrar la rama del feature del servidor remoto y así no tener miles de ramas, una por feature. El comando a ejecutar aquí es directamente de git:
git push origin :feature/<feature>
Release
Una vez terminados todos los features que se querían corregir o implementar, se pasa a crear un release. En términos de git, esto significa hacer un merge a master. Para esto está el comando git flow release start <release>
El resultado de este comando es la creación de una nueva rama con el nombre release/2014-09-20.0 que se puede enviar al servidor para que la puedan descargar los colaboradores.
En este punto se puede hacer Quality Assurance, es decir, todo lo que tenga que ver con testing y aseguramiento de calidad.
Una vez terminado el QA, se finaliza el release con git flow relees finish <release> que pasará todos los cambios a master
Por último se hace limpieza y se envían los tags al servidor
Sobre los nombres de los releases
Al igual que los features, se recomienda usar un formato para nombrar los releases.
El más usado es la fecha en formato AAAA-MM-DD.#, es decir año-mes-día más el número de release por día. Esto en caso de que sea necesario hacer varios varios releases en el mismo día
Corrección de errores
Si lo que se va a hacer es una corrección de errores en producción, se debe usar git flow hotfix start <release> y git flow hotfix finish <release>
Nota Al hacer git flow finish, se hace push tanto a master como a develop. Esto con el fin de no perder en develop los arreglos hechos en master.
Finalmente enviamos a master
Y con esto cerramos el ciclo de git flow
GitHub
Como bono, la forma como se podría trabajar en GitHub sería la siguiente
Conclusión
A la hora de trabajar en proyectos de software, el orden y los estándares toman especial importancia tanto si se va a trabajar en equipo como individualmente. Git flow, aunque no asegura que se sigan estos estándares, ayuda mucho a lograrlos.
Al final, la disciplina de cada programador es la que asegura la calidad del software y git-flow es una herramienta excelente para conseguir esa disciplina.
¿Usas algún tipo de flujo diferente para trabajar con sistemas de versionamiento? ¿Crees que git flow se puede usar diferente? ¿Encontraste un error? Déjanos un comentario.
Actualizado: miércoles, 22 de marzo de 2023