Hablemos un poco sobre control de versiones y GIT

Desde hace ya varios años, llevo trabajando con **git** para el control de versiones de mis proyectos, no se si tube suerte o fue pura casualidad, pero ni siguiera toque a sus abuelos [subversion](https://subversion.apache.org/) o [CVS](https://www.nongnu.org/cvs/), y automáticamente al empezar a usarlo, me di cuenta de que es imposible desarrollar sin esta herramienta. Creo que **git** no necesita presentación alguna, pero puede ser que todavía queden algunas personas que durante los últimos 10 años se encontraban bajo cuevas o bunkers subterraneos y no conoces el **git**. Así que hablemos un poco sobre que es y para que nos sirve. -- Bueno, pues **git** es un sitema de control de versiones que... -- Espera, espera, ¿Qué es el control de versiones? Está bien, asumamos que tu período en el búnker fue más prolongado de lo que inicialmente pensé. Pues te comento que el de control de versiones es la acción de almacenar y controlar todos los cambios por los que atraviesa un producto. Dígase producto a cualquier elemento que en el proceso de su creación, pase por sitemáticas modificaciones de su estructura. -- ¿Pero por qué es importante el control de versiones? Siendo el desarrollo de software el tema principal de Binary Coffee creo que lo mejor es extrapolar esto al desarrollo de software. Mostremos un ejemplo sencillo sobre el control de versiones: Nos encontramos desarrollando nuestro sitio web, y todo está correcto hasta el momento cero que con los últimos cambios que hicimos en el desarrollo de la última funcionalidad todo el sistema se vino abajo, nuestro sitio no funciona, los usuarios estan molestos, los clientes protestan, nuestro jefe se encuentra envuelto en lágrimas en el piso y nosotros resamos ante un altar. Que hacer en esta estresante situación. Pues llegó el control de versiones para salvarnos la vida. Solo tenemos que volver a la versión en que todo era color de rosa y el mundo era bueno con nosotros. Claramente este es el ejemplo más sencillo que podemos compartir, y a lo largo del artículo iremos viendo otros escenarios donde **git** nos salva la vida (literal). Primero creo que hay que hacer una pausa y comentar que **git** fue diseñado por Linus Torvalds (please, no me digas que no lo conoces, porque entonces voy a creer que indudablemente naciste en el búnker), este grande que creó el kernel que lleva su nombre LINUX. Primeramente git fue una herramienta pensada como base para la creación de otras herramientas para el control de versiones, pero en la actualidad es un sistema de control completamente independiente que no necesita de otras aplicaciones para ser utilizado. Ahora que ya sabemos que es el git y para que se usa, creo que es hora de empezar a ver el git aplicado al día a día de un desarrollador: ## Colaboración entre equipos de desarrollo A no ser que sea un proyecto extremadamente sencillo, usualmente se cuenta con un equipo de desarrollo con más de 1 persona. Actualmente puede sonar como algo completamente normal el uso de **git**, pero cuando empecé a desarrollar y a dar mis primeros pasos como programador, rara vez desarrollaba con una segunda persona. Pero en los pocos casos en los que trabajé en equipo, recuerdo que trabajabamos por nuestro lado cada uno, y en algún punto nos encontrábamos y uníamos lo que habíamos hecho. Ni hablar de la locura masiva que se formaba, cuando trabajabamos en un mismo archivo y cuando copiabamos lo del otro, se borraba lo que habíamos hecho, y viceversa. Pues esto terminó cuando encontré al **git**. Con git el trabajo en equipo se hace increíblemente fácil. Incluso sin seguir buenas prácticas es posible desarrollar en equipo con git, aunque se vuelve engorroso a la hora de llevar un trabajo organizado. Cada desarrollador puede trabajar en su funcionalidad y al terminar sube sus cambios al proyecto. Los demás desarrolladores cuando terminen sus funcionalidades hacen lo mismo y si existen conflictos con el trabajo del desarrollador anterior, pues git es lo suficientemente inteligente como para decirnos donde están estos conflictos y poderlos resolver. No quiero hablar mucho en la manera de trabajar con git, porque creo que perfectamente más adelante podemos hacer un artículo completo sobre el tema. Solo quería mencionar, como **git** facilita el trabajo en equipo. ## Control de versiones Como en el ejemplo que mencioné al principio, este es básicamente el principal objetivo de **git**, llevar el control de las versiones del código de nuestro proyecto. Y en cualquier momento, podemos volver a una versión anterior si fuese necesario. Además de esto, es posible chequear quien y cuando hizo los cambios, de esta forma también podemos apuntar el dedo al que destrozó el proyecto (no recomendado :P). Lo curioso de git, es que las versiones del código forman un DAG (para aquellos que gustan de la teoría de grafos), es decir, un Directed Asiclic Graph o lo que sería en español: un Grafo Dirigido sin Ciclos.  Este grafo empieza en el primer commit (definamos un commit como una versión del código) y se va expandiendo a medida que el proyecto va evolucionando. Este tema también es bien interesante y podemos tratarlo en un próximo artículo de cómo manipular este grafo a partir de las operaciones que **git** brinda. ## Automatización de procesos O mejor conocidos como Integración Continua (Continuous Integration) y Despliegue o Entrega Continua (Continuous Deployment). Estos términos son muy conocidos en la actualidad, y es raro ver un proyecto que no los incluya. **Integración Continua**: son el o los procesos que automáticamente se desencadenan luego de la creación de una nueva versión de nuestro código. Dígase como procesos, el ejecutar las pruebas de la aplicación, generación de informes sobre la calidad del código, o otras acciones semejantes. **Despligue Continuo**: es la acción de automaticamente liberar el proyecto a partir de determinadas configuraciones, que en caso de git, puede ser en cada nueva versión del código. ## Organización del flujo de trabajo Existen varias tendendencias en cuanto a como debe trabajarse de manera colaborativa en un proyecto y cada empresa en este aspecto tiene su propio libro. Pero saltan a la vista algunos métodos como son el caso de **git-flow**, que define una serie de reglas a seguir en el desarrollo. O por otra parte github también define su flujo **github-flow**, que define otras reglas a seguir a la hora de trabajar y llevar la evolución de un proyecto. En este aspecto git cumple una gran función dado que todos estos flujos y tendencias para la organización del trabajo en equipo están basada en todos las ventajas y características con las que podemos trabajar. Al final todos estos flujos de trabajo se basan en las ramas, commits, tags y muchas otras cosas. Este tema es muy interesante, y es muy probable que en próximos artículos hablemos sobre el mismo y expliquemos en que consisten estos flujos de trabajo. ## Descentralizado Otra de las grandes ventajas de git, es su caracter descentralizado. A diferencia de algunos de sus abuelos, con git contamos con un control de versiones completamente descentralizado, el simple hecho de clonar un proyecto, implica que estamos clonando el historial completo de versiones de dicho proyecto. Además de que contamos con los **remotes**, que no es más que apuntadores remotos de nuesto árbol de versiones, y estos pueden ser más de uno a la vez, lo que quiere decir, que podemos estar trabajando en un mismo proyecto y tener su código almacenado en gitlab y github al mismo tiempo sin problemas. Esta manera de descentralizar las versiones y evitar su dependencia de un servidor principal, es una de las mayores fortalezas que brinda git. Imagínence que perdemos todos los datos en nuestro servidor junto con todas las versiones de nuestros proyectos. Pues no se ha acabado el mundo, es tan sencillo como que cualquiera de los desarrolladores suba su versión del código (que es un clon de lo que perdimos) y así de fácil todo ha sido recuperado. # Conclusiones Esto ha sido un pequeño repaso de lo que desde mi experiencia, considero los aspectos más importantes de git y el porqué deberías empezar a usarlo si hace poco saliste del búnquer y no te decides en una tecnología aún. De git podemos hablar siglos y es por ello que en muchos casos decidí tocarlos en próximos artículo, dime que crees y si vale la pena hablar más sobre el tema, deja tus comentarios y sugerencias y hasta la próxima. > Happy Coding!