Antes de nada también hay que aclarar que el concepto de control de versiones es un tanto ambiguo y lo podemos encontrar nombrado de diversas maneras: SCM (Source Control Management), CVS (Concurrent Version System), SCS (Source Control System), VC (Version Control)...

A partir de esos nombres ya te puedes imaginar algunos aspectos sencillos:

• La cosa va de control, es decir, hay algo complejo que debemos manejar y gestionar de alguna manera más sencilla que el tomar notas a mano.
• También hay versiones, es decir, un mismo proyecto puede tener varias versiones de su contenido:
  • Las versiones se pueden referir al contenido generado por varias personas, que se deben guardar de manera conjunta (concurrente) en el mismo sitio, porque cada una aporta una parte del trabajo.
  • Las versiones se pueden referir también a los avances que se van produciendo en el contenido de proyecto.

Estoy siendo cuidadoso de no utilizar la palabra código porque, aunque estos sistemas los desarrollaron programadores para gestionar su trabajo en equipo, se pueden utilizar para cualquier otro fin. Como por ejemplo, mantener un montón de cambios en lo artículos de un blog como éste; para hacer un trabajo escolar en equipo; para gestionar un trabajo individual complejo que puede estar sujeto a modificaciones.

¿Qué hace que sea útil un sistema de estos? Ahí van algunas posibles respuestas y no sólo una, sino todas ellas:

• Que tienes la libertad de borrar, mover, cambiar... y arrepentirte sin perder información en ningún momento. Si algo ha estado en el repositorio en una versión anterior, sigue estando en él.
• Que puedes realizar cambios en el proyecto o trabajo y los demás participantes los tendrán de forma inmediata.
• Que puedes tener algunas ramas del trabajo de forma experimental aunque luego, al final, no se integren el resultado definitivo.
• Que puedes volver en el tiempo a versiones anteriores y ver su evolución, o evolucionarlas de forma paralela en otras ramas.
• Que sabes quién, cómo y cuándo, apareció algún contenido en el proyecto, manteniendo una cronología perfecta de la evolución del mismo.
• Que tienes una copia completa en un repositorio remoto. En caso de pérdida, borrado o catástrofe, tienes una copia de seguridad completa de toda la información.

También deberías saber que existen muchos sistemas de estos: algunos son centralizados y otros distribuidos, pero no te preocupes de eso ahora, primero vamos a dar un repaso a los conceptos básicos.

La mayoría de las veces las palabras se corresponden con los conceptos, pero en estos ámbitos no es raro encontrarse que una misma palabra, o comando, en dos sistemas de control de versiones diferentes, no corresponden al mismo concepto, o acción. O encuentras matices que hacen que la coincidencia no sea perfecta. Pero en general, podemos entender:

Repositorio

Es el almacén donde se guarda el contenido, un espacio donde están alojados los archivos y directorios que forman parte del proyecto... en todas sus versiones. Cada participante en el proyecto tiene su repositorio local y suele existir, al menos, uno remoto donde se guardarán los cambios de todos.

Sistema de control de versiones

es un programa que ayuda a mantener un repositorio donde pueden realizar cambios varias personas de manera conjunta.

Commit

se corresponde con la acción de guardar los cambios que hemos hecho en el repositorio. Habitualmente, esos cambios se guardan en el repositorio local.

Trunk

esta es la línea principal o tronco del contenido del repositorio.

Branch

es una escisión de la línea principal. Normalmente se utilizan para añadir características nuevas al contenido del repositorio y nos permiten experimentar sin afectar a la línea principal.

Fork

bifurcación de la línea principal. En algunos sistemas se le llama así a continuar el desarrollo del proyecto de manera paralela al repositorio original. En otros sistemas se utiliza para referirse a una bifurcación generada por la aplicación para resolver problemas de concurrencia. En otros puede ser el simple hecho de hacer una copia local del repositorio general.

Log

listado de los commits de cambios.

Merge

acción de juntar dos ramas del repositorio en una, por ejemplo, para volcar los cambios de una rama en la línea principal.

Pull

acción de descargar al repositorio local los cambios almacenados en un repositorio remoto.

Push

acción de enviar los cambios almacenados en el repositorio local al repositorio remoto.

Sync

acción de sincronizar el repositorio local con el remoto.

Existen otros conceptos y acciones que se pueden realizar en un repositorio, como revertir cambios o situarlo en determinado estado anterior. Pero los enumerados anteriormente son los más básicos y con los que hay que lidiar más a menudo en el trabajo diario.

La gestión de los cambios tiene aspectos diferentes según el tipo de proyecto en el que estés trabajando. Si es un proyecto personal y no es necesario un seguimiento exhaustivo de la evolución del proyecto, el tener el contenido en un sistema de control de versiones, puede ser una forma de mantener una copia de seguridad. Sin embargo, hay todo un arte en subir los cambios al repositorio mediante commits.

Cada commit se convierte en una información valiosa para comprender la evolución del proyecto y cuanto más detallados estén los commits, mejor podrás comprenderlo. Cada uno de ellos lleva aparejado un mensaje de texto, que sería el título, por decirlo así, pero también se pueden añadir más mensajes para detallar el cambio realizado. La mayoría de sistemas abren un editor de texto para facilitarnos el escribir el mensaje del commit. La estructura del commit suele ser:

• Una línea de título del mensaje de commit, que suele ser obligatoria.
• Después de una línea en blanco, en el editor, se puede escribir toda la explicación que se necesite para detallar lo que se ha hecho. Esta parte es opcional, si el cambio es evidente no es necesaria. Desde la línea de comandos se pueden proporcionar varias cadenas de texto para formar el cuerpo.

Una de las pegas que puedes encontrar en el manejo de estas herramientas es la dificultad de montar un repositorio remoto. Suele aparejar el montaje de un servidor que proporcione el acceso al mismo y no es fácil, muchas veces, encontrar un lugar donde situar el remoto al alcance de todos los miembros del equipo.²

Voy a mencionar dos estrategias muy utilizadas, aparte de la mencionada de montar un servidor, que no está al alcance de todos:

• Aprovechar la nube para que nos haga de repositorio.
• Utilizar un servicio de repositorios ya montado.

El control de versiones es una herramienta auxiliar para programación, que se puede utilizar para gestionar (casi) cualquier tipo de proyecto conjunto.

Permite seguir los cambios realizados por los participantes del equipo, especialmente en los contenidos de texto plano.

Es muy recomendable aprender cómo funciona alguno de estos sistemas. Más recomendable aún aprender varios. En mi caso, trabajo habitualmente con git pero en los últimos tiempos, si necesito alguna de las herramientas de forja, utilizo fossil en repositorios locales, en lugar de subirlo a uno público en la red. Aunque cada vez más, necesito esas herramientas, porque utilizo la wiki para anotar ideas, lo tickets para planificar tareas y anotar errores que hay que corregir, etc.