Binary Coffee

Hablemos un poco sobre control de versiones y GIT

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. ![DAG](https://api.binary-coffee.dev//uploads/9c7c484eb26e4f84b013f98c82ffd687.png) 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!
Opiniones
noavatar