Geek & Roll - Blog Archive » Control de versiones para el resto de nosotros

Control de versiones para el resto de nosotros

Cesar September 14th, 2009 aplicaciones, FLOSS 11 comentarios

Imagina que trabajas en tu computadora en algún proyecto. Lo mas probable es que generes uno o varios archivos como resultado de tu trabajo, los cuales se van modificando a medida que avanzas. Imagina ahora que vas a empezar un cambio importante del cual no estas muy seguro. Quien sabe, a lo mejor el cambio no sea de tu agrado, o no sea una buena idea después de todo, o quisieras mantener un punto de referencia: un antes y después.

Si lo primero que se te vino a la mente es una carpeta con varias subcarpetas dentro – una por cada versión del proyecto – bienvenido al club. Esta es la solución mas común, por ser la mas fácil de implementar, rápida y convenientemente integrada al sistema operativo. Yo confieso haber recurrido a esta solución en alguno de mis proyectos, pensando en que me ahorraba algo de tiempo en vez de utilizar un control de versiones en todo el sentido de la palabra. El problema es que mi “sistema de control de versiones” rápidamente se volvió ineficiente cuando surgió la necesidad de agregar mas colaboradores al proyecto o revertir a versiones anteriores.

Probablemente seas:

  • Un diseñador que va a aplicar algunos filtros a una imagen y desea mantener una copia de seguridad “por si acaso”
  • Un músico que tiene varios tracks grabados y va a comenzar a mezclarlos pero no esta seguro y quiere experimentar con varias versiones
  • Un estudiante escribiendo su tesis que desea volver a esa versión anterior de su Capitulo 2. Si, esa misma que su asesor le dijo que quitara, después que siempre no, luego que si pero con los párrafos volteados, luego que el 2 sea el 5 pero similar al 3.
  • O un programador que necesita mantener varias versiones, cambiarse entre trabajar en código de desarrollo y producción, mantener un historial minucioso para poder echarle la culpa a quien sea responsable de que el proyecto no compile, y un largo etc.

La contraparte al control de versiones por carpetas es un software de control de versiones como CVS o SVN. Si no sabes que significan no te preocupes, son herramientas (semi)utilizadas por programadores para mantener un proyecto. Cuentan con un servidor centralizado en donde se guarda todo el historial del mismo, y cada usuario obtiene una versión, trabaja sobre ella, genera algunos cambios y sube esos cambios al servidor. Si no tienes conexión de red no puedes subir tus cambios, y por lo tanto no puedes revertir a una versión anterior o versionar tus cambios actuales. En pocas palabras, bastante inútil.

Y después esta Git. Git también es un control de versiones, pero olvidemonos de eso por un momento. Piensen en Git como un mini filesystem encima de tu filesystem nativo. Es un proyecto que nació de la necesidad de administrar el código fuente de Linux, y si puede mantener un proyecto como Linux con miles de líneas de código y cientos de colaboradores distribuidos alrededor del mundo, seguramente podrá hacer algo por ti.

Ya que mis habilidades de diseñador apestan, y no quisiera dar otro ejemplo de cómo usar Git para administrar un proyecto de software, me voy a poner en el papel del estudiante escribiendo su Tesis. Tenemos una carpeta Tesis con varios archivos: Cap1.txt, Cap2.txt y Cap3.txt.

Lo primero que hacemos es indicarle a Git que queremos mantener las versiones de la carpeta Tesis. Así que entramos a la carpeta y:

git init

Con eso Git esta listo para mantener los cambios dentro de la carpeta Tesis, pero aún tenemos que decirle a Git que archivos va a controlar:

git add .

Ese comando le dice a Git “De ahora en adelante, maneja las versiones de todos los archivos que tengo en la carpeta actual”. El punto después del comando add es para señalar todo lo que está en la carpeta actual. En vez del punto podría ser algo como:

git add *.txt

Lo que agregaría todos los archivos con extensión txt. ¿Pero agregaría a donde? Al index. El index de Git es como una fotografía de cómo se ve el sistema de archivos en ese momento. Git se encarga de versionar lo que tiene en el index, así que si nunca ejecutamos add, nunca versionaremos nada. Para ver lo que tenemos en nuestro index actual:

git status

Y el resultado:

$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached ..." to unstage)
#
# new file: Cap1.txt
# new file: Cap2.txt
# new file: Cap3.txt

Con esto podemos ver que git ha agregado 3 archivos nuevos a su index. Si nos equivocamos y resulta que Cap2.txt no lo queremos versionar por alguna razón, hay que eliminarlo del index:

git rm --cached Cap2.txt

El resultado de esta operación es que Cap2.txt ya no forma parte del index, pero lo seguimos teniendo en el filesystem:

# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached ..." to unstage)
#
# new file: Cap1.txt
# new file: Cap3.txt
#
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# Cap2.txt

Para no dejar por fuera Cap2.txt (no queremos una tesis incompleta):

git add Cap2.txt

Ya nuestro index se ve bien, incluye los 3 capítulos y queremos versionarlo (commit en el jargon del control de versiones):

git commit -a -m "Agregados capítulos 1, 2 y 3"

El switch -a le dice a Git que versione todo lo que tiene en el index, y el switch -m nos permite agregar un mensaje asociado con este commit. El resultado de esta operación:

[master (root-commit) ef2a832] Agregados capitulos 1, 2 y 3
3 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 Cap1.txt
create mode 100644 Cap2.txt
create mode 100644 Cap3.txt

Ya está. Ahora podemos trabajar tranquilamente con cualquier de los capítulos, sabiendo que si cometemos un error podemos volver a una versión anterior. Supongamos que por error borramos el Capítulo 2 (!!) ¿Cómo podemos recuperarlo? Primero veamos lo que nos dice git status:

# On branch master
# Changed but not updated:
# (use "git add/rm ..." to update what will be committed)
# (use "git checkout -- ..." to discard changes in working directory)
#
# deleted: Cap2.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Nos dice que hay cambios, pero no actualizaciones. En efecto el cambio es que borramos el Capítulo 2. También nos sugiere usar checkout — file para descartar los cambios en nuestro directorio de trabajo. Lo que hará el comando es traerse el archivo de donde sea que Git guarde los commits:

git checkout -- Cap2.txt

Después del checkout (obtener archivos que han sido versionados en el jargon del control de versiones) Git stauts nos reporta que no hay cambios. Esto se debe a que el único cambio que había era la eliminación del Capítulo 2, y ahora lo hemos recuperado:

# On branch master
nothing to commit (working directory clean)

Supongamos que después de mucho editar nuestro Capítulo 2, su contenido nos queda así:

Capítulo 2

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Maecenas rhoncus velit molestie erat hendrerit quis accumsan ligula interdum. Mauris eget metus sed felis laoreet auctor. Pellentesque eu felis odio. Morbi pretium viverra mauris, eu suscipit elit interdum ac. Aenean in vestibulum libero. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Nunc nec elit libero. Curabitur et est ligula. Vivamus cursus rutrum augue, a commodo dui adipiscing at. Ut venenatis, ipsum ut scelerisque posuere, tortor enim placerat neque, id sollicitudin nibh leo ut enim. Aliquam erat volutpat. Vivamus non felis et velit condimentum molestie quis eget urna.

Esta versión ya pasó por el proceso de commit. Pero nuestro asesor no está muy contento con el Lorem Ipsum y quiere que le pongamos contenido real. Así que editamos nuestro Capítulo 2 de nuevo y nos queda así:

Capítulo 2

Existen actualmente varias plataformas de hardware y software para la construcción de redes inalámbricas de sensores. Los componentes que forman una red inalámbrica de sensores poseen una arquitectura que la guía principalmente las fuertes restricciones en el consumo de energía y el tamaño del hardware. Sin embargo, no sólo es necesaria una arquitectura de hardware pensada en el ahorro de energía, también se requiere un fuerte acoplamiento en los sistemas de software utilizados para <> este hardware. El resultado es una arquitectura de hardware eficiente en el uso de energía, además de sistemas de software con los que se pueden diseñar protocolos eficientes, utilizando distintas estrategias de ahorro de energía como bajar el voltaje de alimentación, apagar dispositivos independientes, distintos estados de <> del hardware, entre otras.

Y seguros de que nuestro Capítulo 2 r0x0rs, hacemos commit:

git add Cap2.txt
git commit -a -m "Reemplazo de Lorem Ipsum por contenido real"

Pero ahora nuestro asesor de tesis ha decidido que Lorem Ipsum es más interesante que nuestro contenido real, así que quiere que volvamos a esa versión. ¿Qué hacemos? Primero debemos saber el historial de cambio de nuestro Capítulo 2:

git log -- Cap2.txt

El resultado de log es bastante ilustrativo:

commit a27558a49409eea1ca120593b16386c0d36766c5
Author: CesarO
Date: Fri Sep 11 11:01:53 2009 -0700

Reemplazo de Lorem Ipsum por contenido real

commit d763e95015ca121e6242d7d96358c0cbe4dd80ea
Author: CesarO
Date: Fri Sep 11 10:54:56 2009 -0700

Agregado parrafo de Lorem Ipsum

commit ef2a8327f001b0ff957869aefa6d2650fd806485
Author: CesarO
Date: Fri Sep 11 10:04:22 2009 -0700

Agregados capitulos 1, 2 y 3

Vemos que nuestro cambio más reciente es el cambio de Lorem Ipsum por contenido real. El siguiente es cuando agregamos el párrafo de Lorem Ipsum y el último fue el commit inicial. Nosotros queremos volver a Lorem Ipsum así que:

git checkout master~1 Cap2.txt

Esto es como decirle a Git: “De la versión más nueva del Capítulo 2, dame una versión anterior” eso es lo que significa el master~1. De ahí la importancia de poner comentarios que nos ayuden a identificar cada uno de los commits. Para regresar a la versión con contenido real:

git checkout master Cap2.txt

Ya con esto cubrimos gran parte del uso de Git: crear un repositorio, agregar archivos al index, versionarlos y cambiarnos entre una version y otra, aún cuando hayamos borrado el archivo. Hay mucho más que eso en Git, una de las funcionalidades que hace que patee traseros es la capacidad de hacer branches.

Un branch se explica mejor con una imagen:

branches

En la imagen podemos ver que después de reemplazar Lorem Ipsum por contenido real en el Capítulo 2, decidimos volvernos un poco locos y experimentar con generar nuestra tesis con LaTeX. Obviamente este no es un cambio trivial, y podría causarnos problemas así que decidimos hacer un branch y trabajar ahí. Creamos el branch experimental y tambien tenemos el master, que es el que tenemos por default desde el inicio.

Como podemos ver también, al mismo tiempo que se trabajaba en el branch experimental, modificamos el Capítulo 3 en el branch master, porque nuestro asesor nos pidio los primeros 3 capítulos y no podía esperar a que termináramos la rescritura de los capítulos en LaTeX.

Branching, merging, rebasing entre otras cosas son operaciones que se pueden realizar con Git. Sin embargo, para el control de proyectos personales, las operaciones más comunes son las aquí expuestas. Espero que les haya despertado la curiosidad y decidan utilizar Git como sistema de control de versiones. Si nunca han usado uno, están en la mejor posición para aprender ya que dejarán por fuera los vicios aprendidos con otros sistemas.

11 Comentarios

Boynacoras

September 14th, 2009

Si un cabrón esta implementando esto para hacer su tesis, no se para que chingados estudio, se debió haber ido directito a chambiar ya que vaya que tiene talento!
Muy buen post! Creo que google waves va a venir con algunas herramientas para traer un buen versioning a nosotros los mortales.

Cesar

September 14th, 2009

Creo que se me olvido mencionar que el titulo se debe tomar con una pizca de sarcasmo.

Miguel Gastélum

September 14th, 2009

@Boynacoras

O puedes hacer tu tesis de como hacer tesis verisonadas con el sistema para todo el alumnado jejejejej :P, muy buenas ideas pero tal vez para usuarios comunes convenga en modo grafico manejar eso :D seria lo mas facil y mortal como mencionas

Rafyta

September 14th, 2009

TIP: para volverte una celebridad instantánea (y fugaz) haz algún tipo de integración de SVN con twitter, works like a charm.

Boynacoras

September 15th, 2009

No, pero en serio, el Dropbox tiene versioning integrado no?? creo que lo bajaron de ilimitado a 30 dias en la version de a grapa. Y no veo nada mejor integrado con el filesystem que dropbox la neta (dijo el enamorado)

Cesar

September 15th, 2009

No se como funcione el versioning de Dropbox, pero supongo que depende de que estes conectado en la nube no?

Y si quiero, por ejemplo, volver a la version anterior de mi documento y no tengo conexion porque ando en un avion?

mixerfx

September 15th, 2009

Muchas gracias por el artículo ya me diste ideas para mi que voy a empezar a trabajar en mi tesis.
Sigan con esos posts.

Rafyta

September 15th, 2009

@Cesar: si andas volando en el avión, móchate.

Alma

November 25th, 2009

Hola, conincido con Boynacoras.
me piden que elabore un reporte, de como utilizaria las estrategias para el control de versiones, organizando mis asignaturas, archivos, especificando nomenclatura a utilizar, y la verdad sigo sin entender, me podrias ayudar?

Cesar

November 25th, 2009

@Alma: creo que en el post se explica bastante bien cómo usar un control de versiones. Inclusive coincide para el caso de trabajos académicos.

Si necesitas ejemplos más específicos tendrás que hacer una pregunta más específica, tal vez con ejemplos.

Geek & Roll - Blog Archive » Cómo instalar git en Windows

November 13th, 2010

[…] antes he hablado de git, el sistema de control de versiones que me hizo no odiar los sistemas de control de versiones. Git […]

Haz un comentario:

Es necesario que dejes tu nombre y correo electrónico (no se publicarán).

Si dejas un comentario anónimo, con insultos o ajeno al tema, iremos hasta tu casa y le diremos a tu mamá la cantidad de porno que hay en tu computadora. Si, lo sabemos.