El control de versiones

El control de versiones (en inglés, version control) es la práctica de guardar cada estado de un documento o de un programa como una versión con fecha, autor y motivo, de manera que se pueda volver a cualquiera, ver qué cambió entre dos de ellas y trabajar varias personas a la vez sin pisarse. Es lo que sustituye a la carpeta llena de ficheros llamados «informe_final», «informe_final_v2» e «informe_final_DEFINITIVO_bueno», y lo que usa casi todo el software del mundo. El programa más extendido para hacerlo es Git, pero la idea está también en el historial de revisiones de un documento de Google o de un artículo de Wikipedia.

La figura de esta página es un control de versiones en miniatura sobre una receta de cuatro líneas. Cada botón «Editar» cambia una línea, y el cambio no cuenta hasta que se guarda una versión (commit, en la jerga de Git). Cada versión guardada es un círculo del historial, unido a la anterior. Después se puede abrir una rama, cambiar cosas en las dos, fusionarlas y, si las dos tocaron la misma línea, resolver el conflicto a mano.

Lo primero que enseña es que una versión guardada no se modifica nunca. El historial solo crece. Volver atrás no borra lo que vino después, sino que crea una versión nueva igual a una antigua, y por eso un error siempre tiene arreglo: todo lo que alguna vez se guardó sigue ahí. Esa es la diferencia con pulsar «deshacer» en un procesador de textos, que olvida en cuanto se cierra el fichero.

Lo segundo es qué es una rama (branch). Parece una copia del proyecto, pero en Git es solo una etiqueta que apunta a una versión. Al crear «prueba», la figura no copia nada: pone una segunda etiqueta sobre el mismo círculo. Solo cuando se guarda algo estando en esa rama, la etiqueta avanza por su cuenta y el historial se bifurca. Así se puede probar una idea sin tocar la versión que funciona, y tirarla si sale mal. Las empresas de software trabajan de esta manera casi siempre: cada cambio se hace en su rama, alguien lo revisa y solo entonces se fusiona con la principal, que en muchos proyectos se llama main.

Lo tercero, y lo más interesante, es la fusión (merge). Para juntar dos ramas, Git no compara solo sus dos últimas versiones, sino que busca la última versión que tienen en común, el ancestro de las dos, y mira línea por línea quién cambió qué desde entonces. Si una línea solo la cambió una rama, se queda con ese cambio. Si no la cambió ninguna, la deja como estaba. Si las dos la cambiaron exactamente igual, tampoco hay dudas. Solo si las dos la cambiaron de maneras distintas hay un conflicto (conflict), y ahí el programa se niega a adivinar: enseña las dos versiones y espera a que una persona decida. En la figura, si en main se cambian los huevos y en prueba la sal, la fusión sale sola; si las dos ramas cambian los huevos, sale el conflicto. Esa regla de las tres versiones, llamada fusión a tres bandas (three-way merge), es la que permite que cientos de personas trabajen sobre los mismos ficheros y que casi todas las fusiones se resuelvan sin que nadie intervenga.

La historia de estas herramientas es la de ir quitando cerrojos. Marc Rochkind escribió en 1972, en los laboratorios Bell, el primer sistema de este tipo, SCCS, y lo publicó en 1975. Walter Tichy presentó en 1982 RCS, que describió en 1985 y que guardaba solo las diferencias entre versiones para ahorrar espacio. En los dos, para editar un fichero había que bloquearlo, y nadie más podía tocarlo hasta que se soltara. Los sistemas que siguieron, como CVS y Subversion, dejaron trabajar a la vez sobre un servidor central y fusionar después. El último paso fue quitar el servidor: en los sistemas distribuidos, como Git, cada persona tiene en su ordenador una copia completa del historial, puede guardar versiones sin conexión y solo sincroniza cuando quiere.

Git nació de un apuro. El núcleo de Linux, uno de los proyectos de software libre con más colaboradores del mundo, usaba desde 2002 un programa comercial, BitKeeper, cuya empresa les dejaba usarlo gratis. En abril de 2005 retiró el permiso, y Linus Torvalds, el creador de Linux, escribió un sustituto en unos días. La primera versión que guardó Git sobre su propio código es del 7 de abril de 2005, con un mensaje que definía el programa como «el gestor de información del infierno». Tenía que ser muy rápido con un proyecto enorme y fiable frente a la corrupción de datos, y para lo segundo identificó cada versión con la huella de una función hash calculada sobre su contenido y el de su antecesora. Cambiar un solo byte del pasado cambia todas las huellas posteriores, así que el historial no se puede falsificar sin que se note. Hoy Git es, con mucha diferencia, el sistema de control de versiones más usado, y el servicio GitHub, que lo aloja en la nube, se ha convertido en el lugar donde se publica buena parte del software libre.

Para quien no programa, la lección se aplica igual. Un buen mensaje en cada versión, del tipo «cambia la cantidad de huevos» y no «cambios», es lo que hace útil el historial meses después. Guardar a menudo y en pasos pequeños facilita encontrar cuándo se estropeó algo. Y un conflicto no es un error: es la herramienta avisando, con honradez, de que dos personas quisieron cosas distintas en el mismo sitio, algo que en la carpeta de «final_v2» y «final_DEFINITIVO» también ocurría, pero sin que nadie se enterara.

La función hash criptográfica – El software libre – Copia de seguridad – El sistema operativo – Las expresiones regulares – Lenguaje de programación