¿Qué son GIT y GIT FLOW?
Git es un sistema de control de versiones que permite llevar un registro de los cambios que se hacen sobre uno o más archivos, lo que termina siendo un software en el cual puedo informarme sobre quién cambió algo, que cambió y el porqué (Cooper, 2020).
¿Qué no es Git? No es Github (Cooper, 2020). Respuesta escueta, pero poderosa.
“Git es un sistema de control de versiones que nos permite llevar un registro de los cambios que se hacen sobre uno o más archivos”
Exploremos algunos conceptos de Git:
Repositorio (Conocido como Repo):
En un Repositorio podemos guardar los archivos necesarios para nuestros proyectos (Github.com, 2020)
Los repositorios se pueden encontrar en servidores que proveen este tipo de servicios (Como son Github, Bitbucket, Gitlab).
Si bien Git no es el único sistema de control de versiones, es el más popular. siendo usado por la mayoría de los desarrolladores (Open Hub, 2020), ya que permite acciones como guardar el trabajo avanzado, coordinar el trabajo para múltiples desarrolladores en un solo proyecto, manejar diferentes versiones de aplicación en desarrollo, conciliar conflictos en los cambios de un archivo
Ilustración 1. Uso de git en repositorios open source. (Open Hub, 2020).
Ramas (Branches en inglés)
En Git son importantes las ramas (Branches en inglés). Todo repo va a contener una línea de tiempo sobre la cual se marcarán los cambios que se hagan sobre los archivos, ésta sería una Rama.
Una Rama son los registros donde se marcan los cambios que haga uno o varios programadores en un conjunto de archivos en una línea de tiempo (estas características se pueden configurar).
Los repos traen consigo una rama llamada “master” y es la principal en todos los proyectos. A partir de esta rama se pueden crear otras ramas (Por lo tanto, otras líneas de tiempo, y sí, para los Geeks es similar a tener multiversos, ¡como en los Avengers!)
En las ramas que se configuren se pueden administrar cambios de igual forma que en la rama Master sin afectar su contenido. (Es decir, el contenido de la rama Master).
Dado que las ramas son líneas de tiempo se puede configurar a partir de qué momento se creará una rama, a partir de la rama master.
Ilustración 2. Línea de tiempo «master» con una nueva rama creada a partir de un cambio ya hecho en el estado del proyecto.
¿Para qué crear y configurar nuevas ramas? Veamos algunos beneficios:
- Para experimentar nuevas ideas en tu proyecto de forma segura porque podrás tener siempre la rama principal inalterada.
- Podrás solucionar bugs configurando una rama a partir del momento en que surgen, así lo harás con más seguridad y tranquilidad
- Podrás desarrollar y probar nuevas funcionalidades requeridas en tu proyecto antes de integrarlas a tu rama principal para una posterior entrega de valor.
Las ramas podrán ser combinadas para actualizar el contenido en la rama principal o para agregar nuevas funcionalidades en la rama principal, por ejemplo. Así las cosas, las ramas pueden ser mezcladas (Merge), borradas y creadas.
Gitflow
Para establecer un manejo adecuado de las ramas dentro de los repos de Git existen diferentes flujos de trabajo a seguir para generar menos conflictos entre cambios según las mejores prácticas y la lógica de trabajo del equipo del proyecto o iniciativa.
Gitflow es uno de esos flujos de trabajo y se basa en cinco palabras clave durante la construcción de una aplicación y sus respectivas entregas de valor.
Master
Es la rama principal de proyecto , donde va el código para generar la aplicación en entornos de producción. Sobre ella no se debería desarrollar.
Hotfix
Este tipo de rama se crea para la solución de un incidente. Debe ser generada a partir de Master. También se relaciona con el término “cambios en caliente”.
Hotfix se utiliza en ambientes en producción para resolver incidentes.
Develop
En esta rama se tienen las nuevas funcionalidades de la aplicación. No es aconsejable hacer commit (guardar cambios) directamente sobre ella, excepto si son cambios pequeños y que no afecten la lógica, por ejemplo, cambiar un texto.
Feature
Rama generada a partir de la rama develop. Sobre ella se harán los desarrollos de nuevas funcionalidades. Una vez esté desarrollada la funcionalidad la rama feature podrá ser mezclada con Develop para que los cambios queden allí sincronizados, y finalmente se procede a borrar la rama feature. Es aconsejable tener esta rama sincronizada con los cambios que se agreguen a la rama develop para evitar conflictos.
Release
Esta rama utiliza para las entregas a producción o ambiente real. Su propósito es habilitar que en ella se hagan las pruebas del cliente y propender por la calidad de la entrega. Una vez se termine con las pruebas y sean exitosas se mezcla con la rama master. Y se sale a producción.
Es decir que esta rama se crea para hacer el release, y se borra al tenerla integrada con Master.
Ilustración 3 Ejemplo de las diferentes ramas durante el desarrollo de un proyecto.
Flujo de trabajo en un proyecto
En la ilustración 3 podemos apreciar el flujo de trabajo mientras se desarrolla un proyecto.
En la versión 0.1 se hizo la creación del proyecto y aplicación.
A partir de allí se creó una rama develop para el desarrollo de nuevas características, y a su vez se generaron dos ramas feature (con nombres diferentes, pero con la palabra feature en ellas, por ejemplo feature-admin-page) y una de las cuales fue terminada y mezclada con develop.
Si bien el proyecto recién fue creado por algún motivo un incidente surgió y se debe realizar un “cambio en caliente”, por lo que se generó una rama llamada hotfix que permitirá solucionar el incidente y debe ser mezclada con master y develop para luego ser borrada.
Finalmente tenemos la rama release generada a partir de develop y sobre la cual se harán las respectivas pruebas para aprobar o no el código nuevo.
Conclusión
Con un flujo de este tipo hace que el manejo del repositorio y sus ramas sea mucho más lógico reduciendo considerablemente los conflictos generados entre el código de los desarrolladores y al ser tanto podrían generar pérdidas de código o que terminan generando desperdicios de tiempo y reproceso. Además, es una buena práctica de Git junto con muchas otras que te permitirán tener una rápida entrega de valor y que funciona para tecnologías como #javascript, #typescript, #python, #java, #go, #ruby, #php y muchos más.
Una reflexión adicional:
Nosotros vemos necesaria la implementación de herramientas como GitFlow y métodos y herramientas como las que propone DevOps para la maximización de flujo de valor y la minimización del desperdicio, Objetivos fundamentales de Lean – Agile.
Te invitamos a implementar Git o Mejor aún GitFlow y a utilizar Devops en tus proyectos de Software. ¿ Quieres que te ayudemos? –> Escríbenos
Artículo escrito por Álvaro García en colaboración con Juan Andrés Ochoa y Felipe Mejía
Referencias
Cooper, K. (2020, April 19). Understanding Git (part 1) — Explain it Like I’m Five. Retrieved from Hacker Noon: https://hackernoon.com/understanding-git-fcffd87c15a3
Github.com. (2020, April 19). About repositories. Retrieved from Hithub Help: https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-repositories
Open Hub. (2020, April 23). Compare Repositories. Retrieved from Open Hub: https://www.openhub.net/repositories/compare
Mantente al tanto de nuestras publicaciones a través de nuestras redes sociales: LinkedIn, Instagram y Twitter.
