Lobo tuerto

Después de trabajar con algún sistema de control de versiones uno se pregunta como ha podido desarrollar —o vivir jejeje— sin ellos.

El primer VCS (Version Control System — Sistema de Control de Versiones) del cual llegué a escuchar fue el antiguo CVS (Concurrent Versions System).

Aún recuerdo las ventajas que mencionaban algunos amigos acerca de usar un software que te ayudara a llevar un control de los cambios que haces en tu código:

• No tienes que hacer respaldos a mano de tu proyecto — Al ir haciendo commits, automáticamente se van guardando puntos de restauración de tu código.
• Puedes regresar a una fecha determinada o versión de tu código fuente — Gracias a los puntos de restauración que has ido guardando en cada commit que haces.
• Es posible desarrollar en equipo de una manera organizada — Así no pasará que alguien sobreescriba los archivos y cambios de alguien más sin querer.

Mi encuentro con Subversion

En aquel entonces también comencé a escuchar de otro VCS llamado Subversion (SVN) que incluía algunas mejoras significativas sobre los puntos flacos de CVS.

Así que decidí machetearle al SVN un rato, y cuando entendí realmente la utilidad y TODAS las ventajas que traia consigo, lo único que pude pensar fue:

¡¿Cómo he podido estar desarrollando sin un sistema de control de versiones?!

Si, es así de grande la diferencia que hace.

Este artículo no es para explicarles a fondo que es un VCS o SCM (Source Control Management), para ello pueden checar en la Wikipedia:

• El artículo en inglés (el más completo) — Revision control.
• O en español — Control de versiones.

Pero bueno, con experiencia propia en el asunto, he de decir que cualquier desarrollo de software que involucre trabajar en equipo, requiere a fuerza un sistema de control de versiones por sanidad mental.

Es realmente una pesadilla el estar eligiendo a mano y pasando los archivos al “líder de proyecto” en una USB porque éste no quiso aprender a usar Subversion — háganme el favor y si, es el mismo de mi artículo sobre los apuntadores y Java.

A Subversion y CVS se les conoce como sistemas de control de versiones centralizados. Esto es, porque manejan el concepto de un repositorio central donde se almacena el proyecto en su totalidad. Así los clientes se conectan al repositorio central y pueden descargar el código o hacer commits (enviar sus cambios) hacia él.

Descubriendo git

Unos años después me entero de los sistemas de control de versiones distribuidos, y comienzo a leer un poco sobre git.

Decidí probarlo, y después de integrarlo a mi flujo de trabajo cotidiano y entenderlo (si, una cosa es saber sobre algo y otra muy diferente el comprender) únicamente atiné a decir:

¡¿Cómo he podido estar trabajando con Subversion?! Jajaja.

La verdad, después de entender como funciona git, Subversion se antoja a lo menos: restrictivo.

La mayor cualidad que veo en git —cabe mencionar que aún soy neófito en él— es el poder hacer branching (ramificaciones) de tu código a placer y sin un costo significativo asociado, y la facilidad con la que se lleva a cabo el proceso de merging (fusión) de esas ramas experimentales con la rama principal.

git ejemplificado

Creo que la mejor forma de comunicar algo es con un ejemplo. Incluso mi forma preferida de aprender es: Learn by example.

Digamos que tengo una versión estable de mi sistema, y decido implementarle una característica nueva. Lo que hago entonces es crear una rama para trabajar en ella y no afectar la línea principal llamada master:

git branch experimento1
git checkout experimento1

Y listo, lo que haga a partir de este momento con mi código, queda confinado a la rama llamada experimento1.

Puedo hacer básicamente lo que se me antoje: programar alguna característica experimental en mi sistema, hacer algún cambio radical, qué se yo.

Sigo trabajando, hago algunos commits, y si al final veo que lo hecho es satisfactorio y se queda, entonces lo integro a la rama principal con:

git checkout master
git merge experimento1

Sin embargo, si no me agradan los cambios o por alguna razón decido que mejor dejo las cosas como estaban antes de iniciar con experimento1 entonces tecleo:

git checkout master
git branch -D experimento1

Y listo, como si nada hubiera pasado. ¿No es grandioso?

Personalmente considero que git es superior a SVN.

Ya para finalizar quiero comentar que incluso el proyecto Rails, ya se ha cambiado de Subversion a git, no digo que eso sea una demostración de que git es mejor que SVN, pero si que ha llamado la atención de muchas personas y grupos últimamente.

Existen otros VCS distribuidos como Mercurial y Bazaar en caso de que quieran checar algunas alternativas a git.