La arquitectura de Git: Un sistema de control de versiones distribuido

La arquitectura de Git: Un sistema de control de versiones distribuido

  • Autor de la entrada:
  • Categoría de la entrada:Entradas

En 2018, casi el 90% de los 74.000 desarrolladores encuestados por Stack Overflow prefieren usar Git para el control de versiones. Git domina todos los demás sistemas de control de versiones y su adopción ha aumentado casi un 20% desde 2017 según la encuesta. Sin embargo, Git no siempre ha sido tan omnipresente. Echemos un vistazo a su ascenso en la popularidad masiva.

Inicios de Git

Git nació de las frustraciones de la Comunidad del Kernel de Linux con los VCSs (sistemas de control de versiones) disponibles. El desarrollo del kernel de Linux fue bastante inusual para su época: había un gran número de colaboradores en el proyecto, así como una gran variación en la participación de los colaboradores y en el conocimiento de la base de código. Como resultado de la inusual situación de desarrollo del kernel de Linux, los desarrolladores lucharon por encontrar VCS que se ajustaran a sus necesidades. Se conformaron con una mezcla de BitKeeper y el Sistema de Revisiones Concurrentes (CVS), con un grupo de desarrolladores del núcleo trabajando en cada sistema para gestionar el desarrollo del núcleo. BitKeeper proporcionaba un control de revisiones distribuido mientras que el CVS era un sistema de control de versiones cliente-servidor que permitía a los desarrolladores «comprobar» copias del proyecto, hacer cambios y luego «registrar» sus cambios en el servidor.

A principios de 2005, Larry McVoy, titular de los derechos de autor de BitKeeper, anunció la revocación de una licencia que permitía el uso libre del software BitKeeper. Afirmó que Andrew Tridgell, un programador informático australiano que creaba software que interopera con BitKeeper, había realizado ingeniería inversa del código fuente de BitKeeper y violado su licencia. Muchos desarrolladores del núcleo de Linux que confiaban en el software libre de BitKeeper para desarrollar el núcleo de Linux ahora tenían bloqueado su uso.

La relación de la Comunidad Linux con BitKeeper no había sido totalmente libre de conflictos, pero esperaban una alternativa viable antes de dar el salto para alejarse de BitKeeper. Linus Torvalds, el principal desarrollador del kernel de Linux, comenzó a trabajar en un nuevo VCS después de no ver ninguna otra opción libre que satisficiera sus necesidades. En un correo electrónico a la Lista de Correo del Kernel, Linus transmitió cómo estaba contento con BitKeeper y lo que había hecho para el desarrollo del kernel, principalmente que había ayudado al equipo a mantener una visión mucho más fina de los cambios y el seguimiento del conjunto de cambios. Notando que aunque BitKeeper no funcionó, fue muy útil para cambiar la forma en que el núcleo fue desarrollado para mejor.

Desarrollo inicial

Con el fin de proporcionar al equipo una alternativa a BitKeeper, Linus esbozó ciertos criterios de diseño para el nuevo sistema de control de versiones. Quería mantener los beneficios que BitKeeper proporcionaba al equipo, así como desarrollar algunas mejoras.

Se destacaron tres características fundamentales: las salvaguardias contra la corrupción del contenido, el alto rendimiento y los flujos de trabajo de desarrollo distribuidos. Linus también hizo hincapié en que la aplicación de parches no debería llevar más de tres segundos, y citó los sistemas de gestión de control de la fuente que tardaban más de 30 segundos en aplicar un parche y actualizar los metadatos asociados. Es evidente que un sistema de ese tipo no se adaptaría bien a los 250 desarrolladores que trabajan en el núcleo de Linux. A pesar de la temprana influencia de BitKeeper en la creación de Git, Git permite más flujos de trabajo distribuidos y sólo locales que BitKeeper. Los colaboradores del proyecto pueden trabajar en repositorios fuera de línea, comprometerse de forma incremental, determinar cuándo su trabajo está listo para ser publicado, elegir qué cambios compartir, y empujar sus cambios a diferentes ramas.

Visión general de la arquitectura

Un sistema de control de versiones suele tener tres funciones básicas, todas ellas incorporadas por Linus en Git. Debe ser capaz de almacenar el contenido, rastrear los cambios en dicho contenido (todo el historial, incluyendo los metadatos de fusión), y opcionalmente distribuir el contenido y comprometer el historial con los colaboradores del proyecto.

Un gráfico acíclico dirigido

Git utiliza un Gráfico Acíclico Dirigido (DAG) para el almacenamiento de contenidos, así como para comprometer y fusionar historias. Un DAG es un gráfico dirigido que tiene un número finito de vértices y bordes (conexiones entre vértices) que no contienen ciclos (acíclicos). Ser acíclico significa que no hay forma de ir del Nodo A al Nodo B y volver al Nodo A a través de cualquier número de bordes. Un DAG también debe tener un orden topológico. Esto significa que todos los vértices tienen bordes que se dirigen de antes a después en la secuencia (mostrado por las flechas que se mueven de arriba a la izquierda a abajo a la derecha en la imagen de arriba).