Git y las ventajas del control de versiones

Uno de los regalos menos conocidos por el público que nos hizo Linus Torvalds es su sistema de control de versiones “Git”, pues hacer código en equipo no es tan fácil como puede parecer. Cuando este señor abrió su proyecto de un núcleo de sistema operativo al mundo, de forma que cualquiera pudiese colaborar, se encontró con un problema: a la hora de juntar fragmentos de código que le enviaban, tenía que revisar a mano cada uno de los ficheros, para buscar las versiones (fetch),  para traerse los cambios a sus sistema local (pull), para añadir el nuevo código intentando evitar conflictos (por ejemplo que un programador llamó a una variable de una manera y otro de otra, y llegado un punto nos hacemos un lío entre los dos nombres) y guardar la nueva versión (commit), o volver atrás si la hemos liado (revert). Además y proyecto puede dar pie a distintas líneas de desarrollo, bifurcándose (fork) para poder llegar a unirse de nuevo en algún momento (merge). Y todo esto se hacía en los 90 a mano, pegando el código que se enviaba por email.

El caso es que cuando se inventó este sistema, se automatizó la comparación de código, se indicaban los conflictos para resolverlos rápidamente de forma manual y se agilizó muchísimo el proceso, de forma que cuando se trabaja en equipo hoy en día, el control de versiones se ha convertido en una piedra angular. Claro que para que esto sea posible siempre hace falta un par de cosas: lugar en Internet para dejar el código y que todos los participantes en el proyecto puedan sincronizarlo, y un programa amigable de fachada de Git, porque seamos sinceros: el señor Torvalds hace un código de back-end maravilloso que se maneja de lujo desde la consola, pero eso no es precisamente muy amigable para todos (personalmente siempre me gustó usar como cubierta SmarGit, gratuito para uso personal y disponible para Windows, Mac y Linux, pero para gustos hay colores).

De ahí que desde hace años hayan proliferados los repositorios digitales donde almacenar los contenidos y su documentación en forma de wiki, tales como GitHub (actualmente propiedad de Microsoft, y usado como fuente para alimentar su Inteligencia Artifical de pago: ¡nada recomendable!), GitLab (que tiene una versión “Community” de código abierto), Bitbucket (de Atlassian, creadores de Jira, muy bueno para proyectos privados de equipos pequeños), Launchpad (de Canonical, casi todo lo que hay allí es de ecosistema de Ubuntu), SourceForge (nada recomendable hoy en día) o Codeberg (Gitea como servicio, de código abierto).

En mi caso, como prefiero desarrollar sin estar ligada a ninguna plataforma concreta y con plena libertad a la hora de elegir el lenguaje de programación, suelo utilizar GitLab por su sistema de integración de continua y la facilidad de poder desplegar páginas web o pequeñas aplicaciones que mostrar públicamente. Si únicamente me preocupa compartir código fuera de mi red personal, Codeberg me sirve bien para esta función, y es un proyecto por el cual siento más simpatía que por GitLab, que últimamente está más preocupada por sus costes que por su comunidad.