En el desarrollo de software , el control distribuido de versiones (también conocido como control distribuido de revisiones ) 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 ramificación y fusión de la administración automática , 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] [4] Git , el sistema de control de versiones más popular del mundo, [5] 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 tecnología de desarrollo de software en los [últimos] diez años". [2]
Distribuido vs centralizado
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 revisión distribuido sincroniza los repositorios transfiriendo parches de igual a igual. 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:
- Permite a los usuarios trabajar de forma productiva cuando no están conectados a una red.
- Las operaciones comunes (como confirmaciones, visualización del historial y reversión de cambios) son más rápidas para DVCS, porque no es necesario comunicarse con un servidor central. [6] Con DVCS, la comunicación solo es necesaria cuando se comparten cambios entre otros pares.
- Permite el trabajo privado, por lo que los usuarios pueden usar sus cambios incluso para los primeros borradores que no desean publicar. [ cita requerida ]
- Las copias de trabajo funcionan eficazmente como copias de seguridad remotas, lo que evita depender de una máquina física como punto único de falla. [6]
- Permite el uso de varios modelos de desarrollo, como el uso de ramas de desarrollo o un modelo de Comandante / Teniente. [ cita requerida ]
- Permite el control centralizado de la "versión de lanzamiento" del proyecto [ cita requerida ]
- En los proyectos de software FOSS , es mucho más fácil crear una bifurcación de proyecto a partir de un proyecto que está estancado debido a conflictos de liderazgo o desacuerdos de diseño.
Las desventajas de DVCS (en comparación con los sistemas centralizados) incluyen:
- La verificación inicial de un repositorio es más lenta en comparación con la verificación en un sistema de control de versiones centralizado, porque todas las ramas y el historial de revisiones se copian en la máquina local de forma predeterminada.
- La falta de mecanismos de bloqueo que forma parte de la mayoría de los VCS centralizados y aún juega un papel importante cuando se trata de archivos binarios que no se pueden combinar, como activos gráficos o paquetes binarios o XML de archivos únicos demasiado complejos (por ejemplo, documentos de Office, archivos PowerBI, SQL Server Paquetes de BI de herramientas de datos, etc.). [ cita requerida ]
- Se requiere almacenamiento adicional para que cada usuario tenga una copia completa del historial completo de la base de código. [7]
- Mayor exposición de la base del código, ya que cada participante tiene una copia localmente vulnerable. [ cita requerida ]
Algunos sistemas originalmente centralizados ahora ofrecen algunas características distribuidas. Por ejemplo, Subversion puede realizar muchas operaciones sin red. [8] Team Foundation Server y Visual Studio Team Services ahora alojan repositorios de control de versiones centralizados y distribuidos a través del alojamiento 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, [9] que expone un sistema de archivos virtual que solo descarga archivos. al almacenamiento local cuando se necesiten.
Modelo de trabajo
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 fusionarlos (o rechazarlos). El modelo distribuido permite adoptar de forma flexible 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.
Repositorios centrales y de sucursales
Cada proyecto tiene un repositorio central que se considera el repositorio oficial, que es administrado por los mantenedores del proyecto. Los desarrolladores clonan este repositorio para crear copias locales idénticas del código base. Los cambios de código fuente en el repositorio central se sincronizan periódicamente con el repositorio local.
El desarrollador crea una nueva rama en su repositorio local y modifica el código fuente en esa rama. Una vez que se realiza el desarrollo, el cambio debe integrarse en el repositorio central.
Solicitudes de extracción
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 combinación . [10] El colaborador solicita que el encargado del proyecto extraiga el cambio de 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 convertirse en parte de la base de origen. [11]
El desarrollador crea una solicitud de extracción para notificar a los mantenedores de un nuevo cambio; un hilo de comentarios está asociado con cada solicitud de extracción. Esto permite una discusión enfocada de los cambios de código . Las solicitudes de extracción enviadas son visibles para cualquier persona con acceso al repositorio. Los encargados de mantenimiento pueden aceptar o rechazar una solicitud de extracción. [12]
Una vez que se revisa y aprueba la solicitud de extracción, se fusiona con el repositorio. Dependiendo del 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 extracción no probadas. [11] [13] Otros proyectos ejecutan un conjunto de pruebas automatizado en cada solicitud de extracción, utilizando una herramienta de integración continua como Travis CI , y el revisor verifica que cualquier código nuevo tenga la cobertura de prueba adecuada.
Historia
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. [14] El desarrollo de Git , ahora el sistema de control de versiones más popular del mundo, [5] fue impulsado por la decisión de la compañía que hizo que BitKeeper rescindiera la versión gratuita. licencia que Linus Torvalds y algunos otros desarrolladores del kernel de Linux habían aprovechado previamente. [14]
Ver también
- Control de versiones
- Lista de software de control de versiones
- Comparación de software de control de versiones
- Categoría: Software que utiliza el control distribuido de versiones
- Clon de repositorio
- Git , un DVCS de código abierto desarrollado para el desarrollo del kernel de Linux
- Mercurial , un sistema multiplataforma similar a Git
- Fossil , un sistema de control de versiones distribuido, sistema de seguimiento de errores y software wiki
- BitKeeper
- Bazar GNU
- Sistema de versiones concurrentes , un predecesor de los sistemas de control de versiones distribuidos
- TortoiseHg , una interfaz gráfica para Mercurial
- Code Co-op , un sistema de control de versiones de igual a igual
Referencias
- ^ a b Chacón, Scott; Straub, Ben (2014). "Introducción - Acerca del control de versiones" . Pro Git (2ª ed.). Presione. Capítulo 1.1 . Consultado el 4 de junio de 2019 .
- ^ a b Spolsky, Joel (17 de marzo de 2010). "El control de versiones distribuidas llegó para quedarse, bebé" . Joel en software . Consultado el 4 de junio de 2019 .
- ^ "Introducción al control de versiones distribuidas (ilustrado)" . www.betterexplained.com . Consultado el 7 de enero de 2018 .
- ^ "¿Qué es Git? - Explore una herramienta de control de versiones distribuida" . www.edureka.co . Consultado el 7 de enero de 2018 .
- ^ a b "Popularidad de los sistemas de control de versiones en 2016" . www.rhodecode.com . Consultado el 7 de enero de 2018 .
- ^ a b O'Sullivan, Bryan. "Control de revisión distribuido con Mercurial" . Consultado el 13 de julio de 2007 .
- ^ "Qué es el control de versiones: centralizado vs DVCS" . www.atlassian.com . Consultado el 7 de enero de 2018 .
- ^ OSDir.com. "Subversion para usuarios de CVS :: OSDir.com :: Open Source, Linux News & Software" . OSDir.com. Archivado desde el original el 23 de agosto de 2016 . Consultado el 22 de julio de 2013 .
- ^ Jonathan Allen (8 de febrero de 2017). "Cómo Microsoft resolvió el problema de Git con grandes repositorios" . Consultado el 6 de agosto de 2019 .
- ^ Sijbrandij, Sytse (29 de septiembre de 2014). "GitLab Flow" . GitLab . Consultado el 4 de agosto de 2018 .
- ^ a b Johnson, Mark (8 de noviembre de 2013). "¿Qué es una solicitud de extracción?" . Oaawatch . Consultado el 27 de marzo de 2016 .
- ^ "Uso de solicitudes de extracción" . GitHub . Consultado el 27 de marzo de 2016 .
- ^ "Realización de una solicitud de extracción" . Atlassian . Consultado el 27 de marzo de 2016 .
- ^ a b McAllister, Neil. "Error de BitKeeper de Linus Torvalds" . InfoWorld . Consultado el 19 de marzo de 2017 .
enlaces externos
- Ensayo sobre varios sistemas de control de revisiones , especialmente la sección "SCM centralizado vs. descentralizado"
- Introducción a los sistemas de control de versiones distribuidos : artículo de IBM Developer Works