Lo primero que me viene a la mente cuando hablamos de control de versiones o repositorio de software es Subversion o SVN, atrás quedan aquellos momentos en los que era más una herramienta para que un programador tuviera un backup de su código, que una herramienta de trabajo en equipo. Hoy en día pienso en Git y por supuesto aplicando un flujo de trabajo. GitFlow para mí es de gran ayuda para que el equipo de desarrollo pueda lograr la publicación de un proyecto con cierta lógica.
¿Qué es GitFlow?
Imagino que te preguntarás ¿Qué es esto?, no te preocupes no es un nuevo sistema de control de versiones, simplemente es un «flujo de trabajo» en Git con el que un proyecto se va dividiendo en ramas para ayudar al éxito del trabajo y a la publicación final. Como referencia para la redacción de este artículo y por supuesto para mi trabajo diario uso normalmente la guía de Atlasian.
A modo de resumen simplista lo veo como una forma muy útil de coordinar un equipo de trabajo para evitar en la medida de lo posible la generación de conflictos. Además de una posibilidad de tener mucho más control sobre los cambios que acaban en la rama principal del proyecto.
Divide y vencerás
Creo que todos hemos oído en programación la frase de «Divide y vencerás», principalmente en los años de formación. Pues el flujo de trabajo propuesto puede verse de esta forma también.
Con GitFlow lo que hacemos es crear «ramas» para cada funcionalidad que queremos incorporar al proyecto, sin embargo, esas nuevas ramas no van sobre la principal, realmente se crean sobre una rama de desarrollo, en modo esquema sería así:
- Master
- Dev
- Feature Login
Podríamos ver algo parecido a la idea de «GitFlow» en la siguiente imagen:
Al final las funcionalidades que vayamos incorporando al proyecto las desarrollamos en un «branch» o una «rama» nueva sobre la capa de desarrollo (cada funcionalidad nueva es una nueva rama). Cuando está finalizada se agrega a la capa de desarrollo. Se van agregando funcionalidades hasta que alcanzamos un mínimo para publicar o hasta que se nos viene el tiempo encima. En ese momento creamos una rama de publicación o «release» aquí solo se permiten cambios para corregir problemas, documentación y esos trabajos de «pulir» la entrega.
Cuando se tiene esa «release» completa se fusiona con la rama principal y con la de desarrollo. De esta forma las dos ramas tienen los posibles avances y correcciones. Y vuelta a empezar.
¿Cómo empezar?
Vamos a dar por sentado que tienes instalado Git, sin embargo, si aún no has dado ese paso puedes encontrar la instalación para tu sistema operativo (el que tengas) aquí.
Para mí es muy cómodo trabajar con SourceTree (podrás encontrar la instalación aquí), si decides no usar SourceTree o no puedes usarlo, todos los comandos que vamos a realizar con esta herramienta los vas a poder ver en la Referencia de este artículo.
Una vez tenemos las herramientas instaladas voy a establecer una lista con los posibles pasos a seguir para un proyecto, esto no significa que tú puedas leer este artículo y adecuar lo que aquí se expone a tu forma de trabajo o a la de tu equipo.
Ejemplo de GitFlow
Crear un repositorio
A mí particularmente me gusta ir a GitHub primero y crear el repositorio con el que vamos a trabajar. Una de las razones es porque así me aseguro de tener un README en el proyecto donde establecer todas aquellas premisas o indicaciones necesarias. Además nos proporciona ya un GITIGNORE bastante adecuado a lo que normalmente tenemos que excluir según el lenguaje de programación que vayamos a usar.
Clonar el repositorio
Para esto vamos al repositorio creado y copiamos la url para clonar nuestro nuevo repositorio en «local» (nuestro equipo).
Ahora desde SourceTree vamos a clonar el repositorio:
Nos aparecerá una ventana que nos ayudará a realizar este paso, la siguiente imagen va a mostrar el ejemplo de clonación del repositorio que acabamos de crear para este artículo.
Iniciar GitFlow
Ahora ya tenemos el repositorio en local, por lo que vamos a iniciar el flujo de trabajo desde SourceTree, recuerda que antes te comenté que puedes ver todos los comandos para la consola en la guía de referencia cuyo enlace está más arriba.
En la parte superior derecha encontraremos un botón que pone «Git-Flow» si hacemos clic se nos abrirá el asistente para la generación del flujo de trabajo.
Yo particularmente suelo dejar la configuración que viene por defecto porque es suficiente, sin embargo, aquí te puedes sentir libre de realizar los cambios que consideres oportuno/a.
Antes GitFlow que el trabajo – Importante
No sé si te has percatado que aún no hemos tocado Delphi (o tu entorno de desarrollo), no hemos agregado ni una línea de código. Esto es importante, porque tenemos que mentalizarnos que primero es el flujo de trabajo y luego es el trabajo. Es decir, antes de empezar a programar o a documentar o a hacer lo que necesitemos hacer, tenemos que crear la rama que corresponda. Una vez tengamos la rama, podremos empezar a trabajar.
Es un ejercicio que cuesta al principio, pero que una vez lo tienes interiorizado hasta te parece más lógico. De esta forma te aseguras que todo trabajo se genera de forma independiente al código de desarrollo general y limitas los errores y los conflictos.
Funcionalidad
Una vez tenemos el flujo de trabajo creado, vamos a empezar con nuestra primera «Feature» o funcionalidad. Que en nuestro caso será la creación del proyecto. Para eso primero vamos a SourceTree y agregamos la feature correspondiente haciendo de nuevo clic sobre el botón «Git-Flow»:
Al escoger «Start New Feature» se nos abrirá una ventana para indicar el nombre de la nueva funcionalidad y aunque lo lógico es que la rama sobre la que se crea esta nueva rama sea la de «develop» nos permite también elegir otra por si lo necesitas:
Como podemos ver esto no solo nos crea lo necesario, también nos sitúa en la rama que acabamos de crear:
Manos a la obra
Una vez tenemos la estructura creada ahora por fin vamos a Delphi (o nuestro entorno de desarrollo) para crear el proyecto. En esto no vamos a agregar ninguna imagen porque todos sabemos como creamos nuestros proyectos. Yo me voy a limitar a crear el proyecto, así vemos qué va ocurriendo con nuestro repositorio.
Cómo podemos apreciar en la imagen, tenemos los archivos que hemos agregado en nuestro proyecto listos para agregar al primer «Commit«, vamos a agregarlos, confirmaremos los cambios y finalizaremos la «Feature» para que veamos como es el flujo de trabajo.
Finalizando Feature
Una vez hemos finalizado nuestro trabajo, finalizamos también la «Feature» para agregar los cambios a la rama de desarrollo. Para esta tarea también SourceTree nos ofrece sus utilidades, por lo que seguimos en SourceTree y de nuevo clic en el botón «Git-Flow» para finalizar la funcionalidad (Finish Feature):
Una vez tenemos realizado el «commit» vamos a hacer el «push» o subida de los cambios al repositorio. Haciendo clic en el botón «Push» se nos aparece una ventana, marcamos todas las ramas que queremos subir y clic en el botón push de la ventana:
Concluyendo
En este primer artículo hemos dado a conocer una forma de trabajar con Git, por supuesto hay más y cada persona u organización tiene que buscar lo que más le ayude en sus tareas. En el siguiente artículo, veremos como crear otra «Feature» y finalizarla, veremos también como crear una rama «Release» y como fusionarla luego con nuestras ramas principal y de desarrollo.
Como ya sabes, desde nuestra «Academia Abatic» realizamos cursos sobre nuevas tecnologías y estaríamos encantados de crearte un curso donde enseñarte buenas prácticas sobre GIT y como lo utilizamos en nuestra empresa. Por lo que no tengas reparos en ponerte en contacto con nosotros a través de nuestro formulario de Contacto y pedirnos lo que necesites.
Espero te pueda ayudar este primer artículo, te avisaremos por nuestras redes cuando esté la segunda entrega.
Deja una respuesta