Control de versiones con Git (1)

Hola,

Hablar de control de versiones es al mismo tiempo hablar de algo relativamente muy antiguo en la historia de la informática (todavía me acuerdo de usar CVS – Concurrent Versions System en mis prácticas en Unix en mi época de estudiante) y al mismo tiempo algo muy moderno provocado por el auge masivo de repositorios públicos y privados, siendo probablemente Github como quizás el más importante en este renacimiento.

El control de versiones es algo básico en un mundo lleno de programadores donde los equipos de trabajo usan un mismo proyecto y lógicamente necesitan una herramienta que permita distinguir entre versiones en desarrollo, en producción, «ramas» para desarrollar variantes, descartar cambios en caso de errores, evitar conflictos cuando se modifica el mismo fichero y muchas variantes sobre todo esto. Es por tanto una herramienta imprescindible de conocer por parte de cualquier programador, arquitecto software, o jefe de proyecto. Por supuesto, el programador es quien más lo necesita.

Github y webs similares ha potenciado enormemente otros usos, que ya existían, tal como el agrupar voluntarios en el desarrollo de proyectos de software libre, o convertir Github en un centro de aprendizaje (descargando proyectos que funcionan de otros programadores para aprender) o un modo de crear una «huella digital» de los conocimientos de un programador dejando proyectos visibles para demostrar el nivel de conocimientos. También habría que añadir a todo esto que el auge del teletrabajo o de modelos híbridos (parte presencial, parte teletrabajo) ha potenciado en gran medida los repositorios de control de versiones en la nube.

De hecho hay tantos proyectos, tanto código en lugares como Github, que les ha permitido aplicar la Inteligencia Artificial (concretamente OpenIA) para crear Copilot, un asistente para programadores que usen entornos de desarrollo como Visual Studio o Visual Studio Code, así como otros IDEs. Pero esta cuestión la trataré más adelante, en otro artículo.

Ahora es momento de continuar viendo que tipos de sistemas de control de versiones podemos tener para después centrarnos en Git.

Tipos de sistemas de control de versiones

Según el modo de trabajo podemos hablar de 2 tipos fundamentales de control de versiones:

a) Sistemas centralizados (por ejemplo CVS, Subversion): este tipo fue el primero en aparecer y son los que tienen el funcionamiento más simple e intuitivo. Aquí hay un repositorio central y todos trabajan con copias que actualizan a partir del servidor central, al cual también se envían los datos modificados. Así la versión oficial de referencia está centralizado.

• CVS: fue desarrollado por GNU y originalmente usado en sistemas Unix, aunque ahora hay versiones para cualquier otro sistema operativo. Entre sus limitaciones está el soporte limitado de Unicode, así como no poder borrar o renombrar directorios, así como dificultados para hacer lo mismo con los ficheros.
• Subversion (también abreviado como SVN): fue desarrollado por Apache, y tiene características más modernas que CVS. El funcionamiento del repositorio se parece a un sistema de ficheros. No tiene las limitaciones de CVS respecto a crear, renombrar o borrar archivos y carpetas. Su funcionamiento es más óptimo ya que solo guarda las diferencias (CVS enviaba los ficheros enteros aunque solo hubiera cambiado una línea). Maneja de mejor manera ficheros binarios y permite un mejor uso de ramas (brunches), tags (versiones terminadas) y el principal (trunk). Hoy en día muchos de los proyectos importantes que usaron Subversión en sus desarrollos iniciales han migrado a Git. Diría que subversión puede ser una opción para un solo programador o un grupo muy pequeño.

b) Sistemas distribuidos (Git, Bazaar, Mercurial): son más complicados pero más flexibles. En este caso no hay un servidor central, sino que cada programador tiene su propio repositorio que puede sincronizar con los demás. Aunque en la práctica se suele definir un repositorio de referencia para albergar la versión oficial del software. La libertad de tener un repositorio local que no afecte al de referencia dota de gran flexibilidad al desarrollador permitiéndole probar variaciones sin que necesariamente afecte a las versiones de los demás miembros de desarrollo.

• Git: desarrollado por el padre del kernel Linux, Linus Torvals, pensado para un proyecto tan grande y con tantos desarrolladores como es el caso de Linux. En posteriores artículos veremos más sobre su historia, características y uso así como los repositorios en la nube como Github o Bitbucker.
• Bazaar: usado en proyectos importantes como MySQL o Ubuntu lo ha convertido en otro sistema distribuido de control de versiones a tener en cuenta.
• Mercurial: nació también para sistemas Unix/Linux y es usado en proyectos públicos importantes. Está pensado para dar un gran rendimiento y escalable. Su desarrollo coincidió en el tiempo con Git, y el hecho de que finalmente fuera Git el elegido para el desarrollo del kernel de Linux ha hecho que sea menos popular y usado que Git.

Por supuesto, al igual que pasa con los lenguajes de programación, hay muchos más sistemas de control de versiones, pero no veo el sentido de seguir ahondando en este tema, sino en centrarnos en el que actualmente se ha convertido en el más importante y usado, ya que hay que centrar esfuerzos y dedicar tiempo a conocer lo que es más práctico e importante.

Gracias por tu tiempo en leer este primer artículo sobre Git que simplemente da una serie de pinceladas para entender porque es importante y como se compara con el resto de sistemas de control de versiones.