En el desarrollo de software , el control de versiones distribuido (también conocido como control de revisión distribuido ) es una forma de control de versiones en la que la base de código completa , incluido su historial completo, se refleja en la computadora de cada desarrollador. [1] En comparación con el control de versiones centralizado, esto permite la administración automática de ramificaciones y fusiones , acelera la mayoría de las operaciones (excepto empujar y tirar), mejora la capacidad de trabajar sin conexión y no depende de una única ubicación para las copias de seguridad. [1] [2] [3] Git , el sistema de control de versiones más popular del mundo, [4] es un sistema de control de versiones distribuido.
En 2010, el autor de desarrollo de software Joel Spolsky describió los sistemas de control de versiones distribuidos como "posiblemente el mayor avance en la tecnología de desarrollo de software en los [últimos] diez años". [2]
Los sistemas de control de versiones distribuidos (DVCS) utilizan un enfoque de punto a punto para el control de versiones, en contraposición al enfoque cliente-servidor de los sistemas centralizados. El control de versiones distribuido sincroniza los repositorios mediante la transferencia de parches de punto a punto. No existe una única versión central del código base; en su lugar, cada usuario tiene una copia de trabajo y el historial de cambios completo.
Las ventajas de DVCS (en comparación con los sistemas centralizados) incluyen:
Las desventajas de DVCS (en comparación con los sistemas centralizados) incluyen:
Algunos sistemas que originalmente estaban centralizados ahora ofrecen algunas funciones distribuidas. Team Foundation Server y Visual Studio Team Services ahora alojan repositorios de control de versiones centralizados y distribuidos mediante el alojamiento de Git.
De manera similar, algunos sistemas distribuidos ahora ofrecen características que mitigan los problemas de tiempos de pago y costos de almacenamiento, como el Sistema de archivos virtuales para Git desarrollado por Microsoft para trabajar con bases de código muy grandes, [8] que expone un sistema de archivos virtuales que descarga archivos al almacenamiento local solo cuando son necesarios.
El modelo distribuido es generalmente más adecuado para proyectos grandes con desarrolladores parcialmente independientes, como el proyecto del núcleo Linux, porque los desarrolladores pueden trabajar de forma independiente y enviar sus cambios para su fusión (o rechazo). Esta flexibilidad permite adoptar flujos de trabajo de contribución de código fuente personalizados, como el flujo de trabajo del integrador , que es el más utilizado. A diferencia del modelo centralizado donde los desarrolladores deben serializar su trabajo para evitar problemas con diferentes versiones, en el modelo distribuido, los desarrolladores pueden clonar todo el historial del código en sus máquinas locales. Primero confirman sus cambios en sus repositorios locales, creando "conjuntos de cambios", antes de enviarlos al repositorio maestro. Este enfoque permite a los desarrolladores trabajar localmente y desconectados, lo que lo hace más conveniente para los equipos distribuidos. [9]
En un proyecto verdaderamente distribuido, como Linux , cada colaborador mantiene su propia versión del proyecto, y los distintos colaboradores alojan sus respectivas versiones y extraen los cambios de otros usuarios según sea necesario, lo que da como resultado un consenso general que surge de varios nodos diferentes. Esto también facilita el proceso de "bifurcación", ya que todo lo que se requiere es que un colaborador deje de aceptar solicitudes de incorporación de cambios de otros colaboradores y permita que las bases de código se vayan separando gradualmente.
Sin embargo, este sistema puede resultar difícil de mantener, lo que hace que muchos proyectos opten por cambiar a un paradigma en el que un colaborador es el "upstream" universal, un repositorio del que casi siempre se extraen los cambios. Bajo este paradigma, el desarrollo se recentraliza de alguna manera, ya que cada proyecto tiene ahora un repositorio central que se considera informalmente como el repositorio oficial, gestionado por los mantenedores del proyecto de forma colectiva. Mientras que los sistemas de control de versiones distribuidos facilitan a los nuevos desarrolladores la "clonación" de una copia del repositorio de cualquier otro colaborador, en un modelo central, los nuevos desarrolladores siempre clonan el repositorio central para crear copias locales idénticas de la base de código. Bajo este sistema, los cambios de código en el repositorio central se sincronizan periódicamente con el repositorio local y, una vez que se realiza el desarrollo, el cambio debe integrarse en el repositorio central lo antes posible.
Las organizaciones que utilizan este patrón centralizado a menudo eligen alojar el repositorio central en un servicio de terceros como GitHub , que no solo ofrece un tiempo de actividad más confiable que los repositorios autoalojados, sino que también puede agregar funciones centralizadas como rastreadores de problemas e integración continua .
Las contribuciones a un repositorio de código fuente que utiliza un sistema de control de versiones distribuido se realizan comúnmente por medio de una solicitud de incorporación de cambios , también conocida como solicitud de fusión . [10] El colaborador solicita que el responsable del proyecto incorpore el cambio en el código fuente, de ahí el nombre de "solicitud de incorporación de cambios". El responsable del proyecto debe incorporar la solicitud de incorporación de cambios si la contribución debe convertirse en parte de la base de código fuente. [11]
El desarrollador crea una solicitud de extracción para notificar a los encargados del mantenimiento sobre un nuevo cambio; se asocia un hilo de comentarios con cada solicitud de extracción. Esto permite una discusión centrada en los cambios de código . Las solicitudes de extracción enviadas son visibles para cualquier persona con acceso al repositorio. Los encargados del mantenimiento pueden aceptar o rechazar una solicitud de extracción. [12]
Una vez que se revisa y aprueba la solicitud de incorporación de cambios, se fusiona con el repositorio. Según el flujo de trabajo establecido, es posible que sea necesario probar el código antes de incluirlo en la versión oficial. Por lo tanto, algunos proyectos contienen una rama especial para fusionar solicitudes de incorporación de cambios no probadas. [11] [13] Otros proyectos ejecutan un conjunto de pruebas automatizadas en cada solicitud de incorporación de cambios, utilizando una herramienta de integración continua , y el revisor verifica que cualquier código nuevo tenga la cobertura de pruebas adecuada.
Los primeros sistemas DVCS de código abierto fueron Arch , Monotone y Darcs . Sin embargo, los DVCS de código abierto nunca fueron muy populares hasta el lanzamiento de Git y Mercurial .
BitKeeper se utilizó en el desarrollo del kernel de Linux desde 2002 hasta 2005. [14] El desarrollo de Git , ahora el sistema de control de versiones más popular del mundo, [4] fue impulsado por la decisión de la empresa que creó BitKeeper de rescindir la licencia gratuita que Linus Torvalds y algunos otros desarrolladores del kernel de Linux habían aprovechado anteriormente. [14]