Introducción al control de versiones
¿Te suena hacer algún trabajo en el colegio o la universidad y acabar con el escritorio lleno de archivos llamados XXX-final, XXX-final2, XXX-final-esta-vez-si? Cuando generabas todos esos archivos estabas usando una manera rudimentaria de control de versiones, pero…
¿Qué es el control de versiones?
Cuando hablamos de control de versiones nos referimos al uso de un sistema que nos permite volver a puntos concretos del estado de nuestro proyecto o trabajo de manera sencilla. Esto nos permite deshacer cambios que luego no queremos conservar, volver a puntos anteriores de nuestro código, para encontrar el cambio que introduce un fallo que estamos intentando encontrar, o desarrollar varias funcionalidades a la vez.
Conceptos básicos
Empecemos con unos conceptos básicos, los nombres están extraídos de Git, pero lo importante son los conceptos
- Repositorio: conjunto de archivos que tienen la información que queremos guardar, dicho así queda un poco abstracto pero podemos pensar qué es la carpeta en la que guardamos nuestro código (o nuestras recetas).
- Commit: punto de guardado al que podemos volver. Cuando hemos hecho cambios en nuestros archivos y queremos poder volver a este estado, o simplemente no perder estos cambios, hacemos un commit.
- Rama: aquí es donde se empiezan a complicar las cosas. Una rama es un conjunto de commits, en Git siempre tenemos una rama principal o main (antes se llamaba master), de la cual pueden surgir mas ramas, lo veremos más adelante.
- Merge: se trata de unir una rama dentro de otra, esto nos permite ir desarrollando funcionalidades sin afectar a la rama principal.
Ejemplo práctico
Seguramente no te hayan quedado claros los conceptos anteriores, pero veamos un ejemplo práctico y espero que te quede todo mucho más claro.
Volvamos a las recetas e imaginemos que queremos montar una pizzería en la que hacemos muchas pizzas distintas, y para que nos salgan perfectas siempre tenemos un montón de recetas. Recetas de la masa, de las distintas salsas, de las propias pizzas etc… y todas las tenemos en una carpeta en el ordenador de la pizzería.
Como queremos ser la mejor pizzería del mundo tenemos que estar innovando constantemente, no podemos permitirnos usar recetas antiguas, hay que ir mejorándolas, pero no podemos vender cualquier receta que queramos probar.
El problema
Nuestra pasión por la pizza nos lleva a pasarnos las mañanas investigando nuevas recetas, modificando antiguas y explorando nuevas técnicas, y por la noche abrimos el restaurante para nuestros clientes.
¿Cómo llevamos un control de los experimentos sin estropear recetas antiguas? Imagínate que en la salsa de tomate probamos a añadir 50gr de cayena, lo dejamos apuntado en la receta y por algún casual se nos olvida quitarlo antes del turno de noche ¡Todas las pizzas serían picantes! Podríamos guardar una copia del archivo con otro nombre, pero al final tendríamos un montón de archivos con ligeros cambios y posiblemente acabaríamos sin saber cuál es el bueno.
Control de versiones al rescate
¿Cómo nos puede ayudar un control de versiones aquí? Empezaríamos por sólo hacer commits con los cambios que realmente nos gusten, por la mañana probaríamos cosas y, si han quedado bien, haríamos un commit y si no nos convence, volveríamos al commit anterior descartando los cambios. Esto evitaría intoxicar a nuestros clientes por la noche, ya que no se nos colarían experimentos en nuestro turno, pero… ¿y si tardamos más de una mañana en conseguir mejorar una receta?
Empecemos con las ramas
Ahora queremos hacer una nueva salsa de tomate, una técnica totalmente novedosa, que requiere un montón de trabajo de experimentación y que nos llevará semanas. ¿Como podemos guardar el progreso de nuestras investigaciones? Aquí es donde entran en juego las ramas. En nuestro repositorio (nuestras recetas), crearíamos una rama nueva, llamémosla ”super-receta-novedosa-y-secreta-de-salsa-de-tomate-para-pizzas”. ¿Qué pasa ahora? nuestros archivos parecen todos iguales pero hay un pequeño detalle, ahora podemos seguir haciendo todos los commits que queramos y, en cualquier momento, volver a la rama main y… ¡las recetas volverán a estar como antes de crear la rama! Podemos llegar por la mañana al ordenador, entrar a la rama de la nueva salsa de tomate, hacer todos los cambios que queramos y justo antes del turno de noche volver a la rama principal y tener las recetas de siempre.
¿Y cuando encontremos la receta que buscamos?
Hemos estado semanas investigando la nueva manera de hacer la salsa de tomate y por fin queremos estrenarla con nuestros clientes, ¿Qué tenemos que hacer? Aquí es cuando viene el merge o integración. Lo que tenemos que hacer es volcar los commits de nuestra rama de investigación dentro de master, de esta manera todo el progreso que hemos hecho acabará en la rama principal.
La verdadera potencia de tener distintas ramas es poder hacer distintos desarrollos a la vez, podríamos estar investigando una salsa de tomate nueva y a la vez, en otra rama, una receta de masa, y tener todos los cambios organizados y separados.
¿Que sistemas de control de versiones existen?
En la actualidad existen varios sistemas de control de versiones, Subversion, Mercurial etc… pero el más extendido es Git.
No hay que confundir Git con Github, Git es la herramienta software que hay que instalar en el ordenador, Github es una plataforma donde podemos alojar una copia de nuestros repositorios para acceder a ellos de manera remota y distribuida.
Seguramente cualquiera de las herramientas existentes nos servirían para nuestro ejemplo de la pizza, pero ya que Git es la versión más utilizada actualmente, me centraré en ella en próximas entradas.
Esto es solo una introducción al control de versiones, herramientas como Git son mucho más potentes y permiten hacer cosas mucho más avanzadas, pero eso iremos viéndolo más adelante, la siguiente entrada será una introducción de Git a modo guerrilla para poder empezar a usarlo.