En el desarrollo de software , el control de versiones distribuido (también conocido como control de revisiones distribuido ) es una forma de control de versiones en la que el código base completo , 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 bifurcaciones 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 distribuidas 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 igual a igual para el control de versiones, a diferencia del enfoque cliente-servidor de los sistemas centralizados. El control de revisiones distribuido sincroniza los repositorios transfiriendo parches de igual a igual. No existe una versión central única del código base; en cambio, 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 originalmente centralizados ahora ofrecen algunas características distribuidas. Team Foundation Server y Visual Studio Team Services ahora alojan repositorios de control de versiones centralizados y distribuidos a través 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 virtual para Git desarrollado por Microsoft para trabajar con bases de código muy grandes, [8] que expone un sistema de archivos virtual que descarga archivos a almacenamiento local sólo cuando sean necesarios.
El modelo distribuido generalmente es más adecuado para proyectos grandes con desarrolladores parcialmente independientes, como el proyecto del kernel de Linux, porque los desarrolladores pueden trabajar de forma independiente y enviar sus cambios para su fusión (o rechazo). El modelo distribuido permite de manera flexible adoptar flujos de trabajo de contribución de código fuente personalizados. El flujo de trabajo del integrador es el más utilizado. En el modelo centralizado, los desarrolladores deben serializar su trabajo para evitar problemas con diferentes versiones.
En un proyecto verdaderamente distribuido, como Linux , cada contribuyente mantiene su propia versión del proyecto, con diferentes contribuyentes hospedando sus respectivas versiones e incorporando cambios de otros usuarios según sea necesario, lo que resulta en un consenso general que surge de múltiples 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 extracción de otros contribuyentes y permita que las bases de código se separen gradualmente.
Sin embargo, este acuerdo puede ser difícil de mantener, lo que da lugar a que muchos proyectos opten por cambiar a un paradigma en el que un contribuyente es el "ascendente" universal, un depósito del que casi siempre se extraen los cambios. Bajo este paradigma, el desarrollo está algo recentralizado, ya que cada proyecto ahora tiene un repositorio central que se considera informalmente como el repositorio oficial, administrado colectivamente por los mantenedores del proyecto. Si bien los sistemas de control de versiones distribuidos facilitan a los nuevos desarrolladores "clonar" 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 del código base. Bajo este sistema, los cambios de código en el repositorio central se sincronizan periódicamente con el repositorio local y, una vez finalizado el desarrollo, el cambio debe integrarse en el repositorio central lo antes posible.
Las organizaciones que utilizan este patrón de centralización a menudo optan por 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 autohospedados, sino que también puede agregar características 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 mediante una solicitud de extracción , también conocida como solicitud de fusión . [9] El colaborador solicita que el responsable del proyecto realice el cambio en el código fuente, de ahí el nombre "solicitud de extracción". El mantenedor tiene que fusionar la solicitud de extracción si la contribución debe pasar a formar parte de la base de origen. [10]
El desarrollador crea una solicitud de extracción para notificar a los mantenedores sobre un nuevo cambio; un hilo de comentarios está asociado 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 mantenedores pueden aceptar o rechazar una solicitud de extracción. [11]
Una vez que la solicitud de extracción se revisa y aprueba, se fusiona en el repositorio. Dependiendo del flujo de trabajo establecido, es posible que sea necesario probar el código antes de incluirlo en el lanzamiento oficial. Por lo tanto, algunos proyectos contienen una rama especial para fusionar solicitudes de extracción no probadas. [10] [12] Otros proyectos ejecutan un conjunto de pruebas automatizadas en cada solicitud de extracción, utilizando una herramienta de integración continua , y el revisor verifica que cualquier código nuevo tenga una cobertura de prueba adecuada.
Los primeros sistemas DVCS de código abierto incluyeron 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 de 2002 a 2005. [13] El desarrollo de Git , actualmente 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 el sistema gratuito licencia que Linus Torvalds y algunos otros desarrolladores del kernel de Linux habían aprovechado anteriormente. [13]