En 2010, Vincent Driessen escribió “A successful Git branching model”. Proporcionó un gran modelo para desarrollar aplicaciones en un repositorio organizado y siguiendo los conceptos de control de versiones semánticas, por lo que los equipos pudieron planificar lanzamientos, implementar funciones y revisiones sabiendo y reflejando los cambios en el repositorio GIT de manera consistente.
En Swapps, confiamos mucho en este método durante varios años, y rápidamente descubrimos que este método funciona principalmente cuando estamos trabajando en un proyecto con lanzamientos planificados y un equipo dedicado. En nuestro caso, trabajamos en diferentes proyectos al mismo tiempo, algunos de ellos están en etapa de desarrollo y otros están en modo de mantenimiento. Este enfoque se explica en un artículo anterior: “Sea menos ágil para ser más ágil”.
Hay artículos que dicen que Git Flow puede ser dañino “Git Flow can be harmful” y proponen una alternativa más sencilla. Entiendo las razones y también me gusta la sencillez, pero ¿a qué precio? Si un enfoque complica un proyecto, es posible que debamos reconsiderarlo.
Gitlab y Github han dado alternativas simplificadas donde proponen eliminar por completo las ramas de release y hotfix para tener solo una rama master y ramas de features todo el tiempo. Eso funciona bien para proyectos sin trabajo paralelo y características muy específicas y aisladas, pero en la vida real es muy común trabajar en problemas relacionados (por ejemplo, un sprint ágil) y necesitas una rama intermedia (la próxima rama de release o la de develop) para probar todo junto antes de implementarlo.
Para resolver eso, eliminan la equivalencia de master y producción y configuran manualmente las etiquetas o simplemente implementan manualmente (Github Flow) o incluso peor, crean una rama adicional para la producción (Gitlab Flow).
No sé qué piensas, pero creo que no vale la pena perder la automatización o agregar una rama para algo que ya está resuelto y estandarizado.
En otro artículo, mostraremos cómo automatizamos la implementación y la creación de etiquetas en función de nuestro flujo de Git.
Hemos propuesto un enfoque más simple donde mantenemos las ventajas del Flujo Git original, el repositorio permanece estructurado, el flujo de trabajo se simplifica un poco y automatizamos lo repetitivo.
La clave es tener la posibilidad de tener un enfoque más simple como el propuesto por Github, pero aún tener la opción de tener lanzamientos con varias características cuando sea necesario.
Master significa producción, y es la rama conectada directamente al entorno donde reside la aplicación en vivo, por lo que tenemos nuestro flujo de trabajo de integración continua configurado para implementarse automáticamente en cualquier cambio en master
Se le permite crear features o ramas de hotfix basadas en master y luego crear pull requests para master, para que se implemente automáticamente.
Las versiones son importantes porque agrupan el historial del desarrollo en términos de lanzamientos, por lo que tienes en tu repositorio cómo y cuándo se implementó el código. ¿Ves por qué es importante vincular lanzamientos e implementaciones?
Al seguir el control de versiones de SEM, siempre comenzamos con una versión menor definida, Ej. 0.1,1.0. Entonces, dependiendo de si estamos creando un pull request de una función a master o de una rama de lanzamiento a master, debemos definir la versión correcta para usar:
Para los siguientes ejemplos, asumiremos que comenzamos nuestro proyecto con la versión 0.1.0.
Esto es especialmente útil para proyectos en modo de mantenimiento. Simplemente cree todas sus ramas de funciones basadas en master y creará parches para su aplicación.
Ejemplo:
En un contexto tradicional, habríamos llamado esas funciones como hotfixes, pero mantengamos las cosas simples en la convención de nomenclatura por ahora.
Se utiliza cuando planea implementar un conjunto de funciones, por lo que crea una rama de versión basada en la versión master y todas sus features se basarán en la versión específica.
Cuando sea el momento de lanzar todas las features, creará un pull request desde la rama de lanzamiento a master.
Ejemplo:
Como pudo ver en los ejemplos anteriores, administramos las características de una versión en una versión de rama separada / x.x, mientras que los hotfixes se administran a través de parches y se fusionan directamente con master. Significa que podemos trabajar en hotfixes mientras estamos trabajando en una rama de lanzamiento sin problemas.
Esta es una de las desventajas del enfoque de Git Flow. Somos humanos y nos olvidamos de cosas como actualizar la rama de lanzamiento con los cambios más recientes en master. Si no quiere tener problemas, necesita encontrar una manera de mantener la rama de lanzamiento siempre actualizada.
Hemos proporcionado una alternativa al flujo estándar de Git que pretende obtener lo mejor de ambos mundos: robusto y simple, y explicamos por qué los enfoques proporcionados por Github y Gitlab no se ajustan a nuestras necesidades. Como siempre, puede utilizar cualquier enfoque que funcione mejor para usted. Lo más importante es que usted y su equipo comprendan el flujo de trabajo y mantengan la coherencia para que cualquier otro visor de repositorios futuro pueda entender.