¡Tú eres el Doc, Doc! Viaja en el tiempo con el control de versiones en tus desarrollos

Autor: Daniel G.

(Imagen: Back to the Future, producida por Steven Spielberg/Robert Zemeckis. 1985. Estados Unidos. Amblin Entertainment)

¿Alguna vez te ha pasado que al modificar algunas líneas de código tu proyecto ya no funciona como antes? O ¿planchaste o te plancharon los cambios porque algún compañero trabajó en el mismo archivo que tú?

La mayoría de los desarrolladores se han enfrentado a esta situación: ¿Cómo agregar nuevos cambios sin que estos afecten al correcto funcionamiento de la aplicación? O si trabajas en equipo: ¿Cómo evitar que los cambios que realice no afecten a los de mis compañeros?

Se han dado muchas soluciones a esto, como es el caso de guardar una serie de carpetas con la clásica frase: “el_ultimo” o la frase que nunca debe faltar “este_es_el_final”. Pero, ¿Estas soluciones son lo mejor?

El inconveniente que se ve con estas soluciones es que si pierdes el archivo no podrás volverlo a ubicar y a su vez la integración de este archivo tendría que ser manual, de tal manera que te verías obligado a revisar línea por línea de tu código, compararlo con el nuevo y todavía faltaría revisar si este funciona.

Existe una solución que te permite viajar por el tiempo entre las diferentes etapas de tu aplicación y además agregar cambios de otros compañeros con mucha facilidad. Esta solución se llama “Control de versiones”.

Para evitar entrar en cuestiones técnicas utilizaré un ejemplo muy simple y que algunos de nosotros ya vimos en nuestra infancia: La película “Volver al Futuro II”. Existe una escena donde el “Doc” Emmett Brown explica a Marty McFly el porque todo el presente cambio a causa del robo del Almanaque. En nuestro ejemplo usaremos ese dibujo para nuestro ejemplo.

(Imagen: Back to the Future, producida por Steven Spielberg/Robert Zemeckis. 1985. Estados Unidos. Amblin Entertainment)

Si nos damos cuenta existe una “linea que representa el tiempo” si la expresamos en términos de un control de versiones, representa el ciclo de vida que a tenido nuestro proyecto, a esta línea la llamaremos “rama master” en la cual se encuentra desde el inicio hasta la etapa actual de nuestra aplicación. Cada acción o modificación que realizamos en nuestro aplicativo sobre la “rama master” queda registrado en un repositorio e incluso podemos agregar una descripción del cambio que se hizo. A este registro le llamaremos “commit”.

A cada commit se le asigna un identificador alfanumérico para que pueda ser ubicado dentro de nuestro repositorio. Con este dato podemos viajar hacia cualquier etapa de nuestro proyecto, es como “viajar en el tiempo”.

Volvamos a la película, al punto donde el “Doc” explicaba lo ocurrido cuando él menciona que se crea una tangente a partir de la línea del tiempo original creando una realidad alterna. En nuestro control de versiones podemos crear también realidades alternas a nuestra “rama master” a estas líneas simplemente las llamaremos “ramas” y podemos crear tantas como el proyecto lo requiera e identificarlas con un nombre.

Si la “rama master” es una “rama” y dicha “rama” tiene “commits” entonces también en las ramas que creamos podemos registrar commits y así mismo viajar a través de ellas de tal forma que podemos regresar a etapas donde nuestro proyecto era estable, en caso de que así se requiera.

Otra de las ventajas que puede utilizarse en el control de versiones es la capacidad de mezclar dichas “ramas” para obtener modificaciones que se realizaron en esas “realidades alternas” facilitando la integración de cambios que algún compañero realizó y así solo preocuparse por revisar el correcto funcionamiento de la aplicación.

Y ahora que ya sabes las ventajas de un control de versiones, aplicalo a tus proyectos en el futuro y veras que es más fácil viajar por el tiempo usando esta herramienta.