El increíble Git I. Introducción


Hola comunidad, este es el primero de una serie de artículos que dedicaré al trabajo con el Sistema de Control de Versiones Git, en los que se abordarán las principales características de este software, las bondades que brinda, la necesidad del uso de Sistemas de Control de Versiones (VCS en lo adelante, siglas en inglés de Version Control System) y las razones por las cuales Git es uno de los VCS más populares.

Primeramente destacar que un VCS no solo es útil a las personas dedicadas al desarrollo de software. Si eres escritor o estás haciendo una tesis de grado o algún otro escrito que requiera el uso de borradores, los cuales son revisados y modificados constantemente para mejorarlos y crear la versión final, debes conocer que un VCS como Git te puede ser muy útil en la organización y administración de ese tan importante trabajo.

Como el término indica, un VCS se utiliza para tener un control de las distintas “versiones” que generas en la creación de un proyecto, sin embargo, estos permiten además que otros puedan colaborar contigo de una manera extremadamente cómoda y transparente.

Muchas personas no entienden la necesidad de utilizar un VCS, y creen que lejos de ser una herramienta poderosa para administrar su código fuente (en el caso de los desarrolladores) es más bien un estorbo que los obliga a aprender a interactuar con ” otro sistema más”, resultando en una pérdida de tiempo. Esto es verdadero en un 50%, pues en efecto, debes aprender a interactuar con “otro sistema más”, sin embargo, su uso resultará en un grandísimo ahorro de tiempo y esfuerzos en cuanto a organización y colaboración se refiere.

Personalmente, antes de utilizar un VCS para gestionar mis proyectos, yo contaba con un sistema propio de control de versiones. Cada vez que terminaba un requisito importante del software que estaba construyendo, y al comenzar uno nuevo que posiblemente incluyera bugs (errores) a la aplicación, con una gran sonrisa en mi cara copiaba y pegaba todo mi código fuente en una nueva carpeta, nombrándola con el mismo nombre anterior, pero adicionándole la fecha y hora actual, y opcionalmente un nombre corto al final que me sirviera para recordar qué fue lo que hice en esa versión de la aplicación.

Ese mecanismo fue “útil” en cierta medida para proyectos pequeños, pero especialmente en ésta aplicación, luego de varios meses de trabajo, ver más de 30 carpetas con diferentes fechas simplemente se volvió en un inútil basurero de código fuente. ¿Por qué? He aquí algunas razones:

  1. Código repetido. El mismo código se repite una y otra vez, generando muchos archivos que aunque no se modifican de una versión a otra, se necesitan copiar para que la aplicación siga funcionando. Ejemplo: si la aplicación es un sitio web que utiliza jQuery, y se cuenta con 15 versiones diferentes, esta biblioteca estará repetida 15 veces.
  1. Suponiendo que la aplicación está estable y se crea una nueva versión para trabajar en los requisitos X y Z, si al terminar ambas características se detectan errores difíciles de reparar y se decide que no es necesario por el momento implementarlas, se debe entonces manualmente desechar esa carpeta y comenzar de nuevo en la versión anterior, por lo que es necesario en el cambio hacia esa versión, eliminar de tu editor de código fuente el proyecto defectuoso y cargar nuevamente el proyecto estable.
  1. Modificando el ejemplo anterior y suponiendo que luego de terminadas las características X y Z (y antes de darnos cuenta que éstas no son necesarias) se le entrega el proyecto a un amigo para que trabaje en el requisito M, si en el mejor de los casos este requisito no depende de los demás, cuando el amigo te entregue su nueva versión con el requisito listo, la integración entre tu versión y la de tu amigo será necesario hacerla de forma manual, o sea, abrir ambos proyectos y copiar y pegar las nuevas rutinas implementadas hacia la versión estable de la aplicación. Esto puede llegar a ser un gran dolor de cabeza, pues tal requisito M, aunque independiente de los demás, pudo fácilmente haber sido implementado en varios ficheros existentes, haciendo aún más difícil la integración.

Todos estos problemas básicos se resuelven con el simple hecho de utilizar un VCS. Siempre contarás con una sola carpeta de tu proyecto, te podrás mover hacia las distintas versiones con un simple clic y en el peor de los casos con un comando. Podrás además crear versiones para los distintos requisitos, con la facilidad de no tener que lidiar con ambos al mismo tiempo, o sea, podrás crear una versión del proyecto para el requisito A, una versión para el requisito B y trabajar en ambos de forma aislada o en paralelo, y luego “unir” ambas versiones para crear la versión final, esto es a lo que se le llama branching (desarrollo en ramas) en los VCS.

Con lo anterior expuesto, creo que en este momento debes tener la siguiente pregunta en el primer escalón de tu mente: si existen varios VCS, ¿por qué Git? La respuesta a esta y otras interrogantes serán respondidas en las consecuentes partes de “El increíble Git”. Mientras, espero haberte convencido de la necesidad de utilizar un VCS para administrar tus proyectos (objetivo principal de esta primera parte) y con más, espero encontrarte nuevamente en el próximo episodio.

PD: Si ya utilizas algún VCS para administrar tus proyectos y tienes anécdotas que contarnos de cuando no lo utilizabas, no dudes en compartirlas en la sección dedicada a los comentarios :)