Hispanopedia Wiki
Articulo de referencia

Control de versiones distribuido

El proceso de inicialización de un repositorio Git. Git es uno de los programas de control de versiones distribuidos más utilizados. En el desarrollo de software , el control de...

Hispanopedia WikiContenido en espanolLectura gratuita
El proceso de inicialización de un repositorio Git. Git es uno de los programas de control de versiones distribuidos más utilizados.

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 fuente completo , incluyendo su historial completo, se replica en el ordenador de cada desarrollador. [ 1 ] En comparación con el control de versiones centralizado , esto permite la gestión automática de ramificaciones y fusiones , acelera la mayoría de las operaciones (excepto push y fetching), 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.

Distribuido versus 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 revisiones distribuido sincroniza los repositorios transfiriendo parches entre nodos. No existe una única versión central del código fuente; en cambio, cada usuario dispone de una copia de trabajo y del historial completo de cambios.

Las ventajas de los sistemas 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 con DVCS, ya que no es necesario comunicarse con un servidor central. [ 5 ] Con DVCS, la comunicación solo es necesaria al compartir cambios entre otros pares.
  • Permite el trabajo privado, de modo que los usuarios pueden utilizar sus cambios incluso en borradores iniciales que no deseen publicar.
  • Las copias de trabajo funcionan eficazmente como copias de seguridad remotas, lo que evita depender de una máquina física como un único punto de fallo. [ 5 ]
  • Permite utilizar varios modelos de desarrollo, como ramas de desarrollo o un modelo de Comandante/Teniente. [ 6 ]
  • Permite el control centralizado de la "versión de lanzamiento" del proyecto.
  • En los proyectos de software libre, es mucho más fácil crear una bifurcación de un proyecto que se encuentra estancado debido a conflictos de liderazgo o desacuerdos de diseño.

Las desventajas de los sistemas DVCS (en comparación con los sistemas centralizados) incluyen:

  • La extracción inicial de un repositorio es más lenta en comparación con la extracción en un sistema de control de versiones centralizado, porque todas las ramas y el historial de revisiones se copian a la máquina local de forma predeterminada.
  • La falta de mecanismos de bloqueo, que forma parte de la mayoría de los sistemas de control de versiones centralizados y que aún desempeña un papel importante en lo que respecta a archivos binarios no fusionables, como recursos gráficos o paquetes binarios o XML de un solo archivo demasiado complejos (por ejemplo, documentos de Office, archivos de Power BI, paquetes de BI de SQL Server Data Tools, etc.).
  • Almacenamiento adicional necesario para que cada usuario tenga una copia completa del historial completo del código fuente. [ 7 ]
  • Mayor exposición del código fuente, ya que cada participante dispone de una copia localmente vulnerable.

Algunos sistemas originalmente 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 Git.

De manera similar, algunos sistemas distribuidos ahora ofrecen características que mitigan los problemas de los tiempos de extracción y los 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 al almacenamiento local solo cuando son necesarios.

Modelo de trabajo

Un modelo distribuido suele ser más adecuado para proyectos grandes con desarrolladores parcialmente independientes, como el kernel de Linux . Permite a los desarrolladores trabajar en ramas independientes y aplicar cambios que posteriormente pueden ser confirmados, auditados y fusionados (o rechazados) [ 9 ] por otros. Este modelo ofrece mayor flexibilidad y permite la creación y adaptación de ramas de código fuente personalizadas ( forks ) cuyo propósito puede diferir del del proyecto original. Además, permite a los desarrolladores clonar localmente un repositorio de código existente y trabajar en él desde un entorno local donde los cambios se registran y se confirman en el repositorio local [ 10 ], lo que permite un mejor seguimiento de los cambios antes de su confirmación en la rama principal del repositorio. Este enfoque permite a los desarrolladores trabajar en ramas locales y desconectadas, lo que resulta más conveniente para equipos distribuidos de mayor tamaño.

Depósitos centrales y sucursales

En un proyecto verdaderamente distribuido, como Linux , cada colaborador mantiene su propia versión del proyecto. Cada colaborador aloja su propia versión y recibe los cambios de otros usuarios según sea necesario, lo que da como resultado un consenso general que surge de múltiples nodos. Esto también facilita el proceso de bifurcación, ya que basta con que un colaborador deje de aceptar solicitudes de extracción de otros colaboradores y permita que los repositorios de código se separen gradualmente.

Sin embargo, este sistema puede ser difícil de mantener, lo que lleva a muchos proyectos a optar por un paradigma en el que un colaborador actúa como repositorio central, del cual casi siempre se obtienen los cambios. Bajo este paradigma, el desarrollo se recentraliza, ya que cada proyecto cuenta con un repositorio central que se considera informalmente el repositorio oficial, gestionado colectivamente por los responsables del proyecto. Si bien los sistemas de control de versiones distribuidos facilitan a los nuevos desarrolladores la clonación 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 fuente. En 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 suelen optar por alojar el repositorio central en un servicio de terceros como GitHub , que no solo ofrece un tiempo de actividad más fiable que los repositorios autogestionados, sino que también puede añadir funciones centralizadas como sistemas de seguimiento de incidencias e integración continua .

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 (pull request) , también conocida como solicitud de fusión (merge request) . [ 11 ] El colaborador solicita al mantenedor del proyecto que extraiga el cambio en el código fuente, de ahí el nombre de "solicitud de extracción". El mantenedor debe fusionar la solicitud de extracción para que la contribución pase a formar parte de la base de código fuente. [ 12 ]

El desarrollador crea una solicitud de extracción para notificar a los mantenedores sobre un nuevo cambio; cada solicitud de extracción tiene un hilo de comentarios asociado. 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. [ 13 ]

Una vez revisada y aprobada la solicitud de extracción, se integra al repositorio. Según el flujo de trabajo establecido, es posible que el código deba probarse antes de su inclusión en la versión oficial. Por lo tanto, algunos proyectos incluyen una rama especial para integrar las solicitudes de extracción no probadas. [ 12 ] [ 14 ] 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 el código nuevo cuente con la cobertura de pruebas adecuada.

Historia

Los primeros sistemas DVCS de código abierto fueron Arch , Monotone y Darcs . Sin embargo, los DVCS de código abierto no fueron muy populares hasta el lanzamiento de Git y Mercurial .

BitKeeper se utilizó en el desarrollo del núcleo de Linux desde 2002 hasta 2005. [ 15 ] 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 revocar la licencia gratuita de la que Linus Torvalds y otros desarrolladores del núcleo de Linux se habían beneficiado previamente. [ 15 ]

Véase también

Referencias

  1. 1 2 Chacon, Scott; Straub, Ben (2014). "Acerca del control de versiones" . Pro Git (2.ª  ed.). Apress. Capítulo 1.1 . Recuperado el 4 de junio de 2019 .
  2. ↑ Spolsky, Joel (17 de marzo de 2010). "El control de versiones distribuido llegó para quedarse, cariño" . Joel on Software . Recuperado el 4 de junio de 2019 .
  3. ↑ "Introducción al control de versiones distribuido (ilustrado)" . www.betterexplained.com . Consultado el 7 de enero de 2018 .
  4. 1 2 "Popularidad de los sistemas de control de versiones en 2016" . www.rhodecode.com . Consultado el 7 de enero de 2018 .
  5. 1 2 O'Sullivan, Bryan. "Control de revisiones distribuido con Mercurial" . Recuperado el 13 de julio de 2007 .
  6. ↑ Chacon, Scott; Straub, Ben (2014). "Flujos de trabajo distribuidos" . Pro Git (2.ª ed.). Apress. Capítulo 5.1. 
  7. ↑ "¿Qué es el control de versiones: centralizado frente a DVCS?" . www.atlassian.com . 14 de febrero de 2012 . Consultado el 7 de enero de 2018 .
  8. ↑ Jonathan Allen (2017-02-08). "Cómo Microsoft resolvió el problema de Git con los repositorios grandes" . Recuperado el 2019-08-06 .
  9. ↑ "Envío de parches: la guía esencial para incorporar tu código al kernel — Documentación del kernel de Linux" . www.kernel.org . Consultado el 22 de noviembre de 2024 .
  10. ↑ "Git - Selección de revisión" . git-scm.com . Consultado el 22/11/2024 .
  11. ^ Sijbrandij, Sytse (29 de septiembre de 2014). "Flujo de GitLab" . GitLab . Consultado el 4 de agosto de 2018 .
  12. 1 2 Johnson, Mark (8 de noviembre de 2013). "¿Qué es una solicitud de extracción?" . Oaawatch . Recuperado el 27 de marzo de 2016 .
  13. ↑ "Uso de solicitudes de extracción" . GitHub . Consultado el 27 de marzo de 2016 .
  14. ↑ "Cómo hacer una solicitud de extracción" . Atlassian . Consultado el 27 de marzo de 2016 .
  15. 1 2 McAllister, Neil. "El error de Linus Torvalds con BitKeeper" . InfoWorld . Recuperado el 19 de marzo de 2017 .
  • Ensayo sobre diversos sistemas de control de revisiones , especialmente la sección "Sistemas de control de versiones centralizados frente a descentralizados".
  • Introducción a los sistemas de control de versiones distribuidos - Artículo de IBM Developer Works
Obtenido de " https://en.wikipedia.org/w/index.php?title=Distributed_version_control&oldid=1349097587#Pull_requests "
Lecturas relacionadas
6 articulos
Desarrollo de softwareDesarrollo de softwareEl desarrollo de software es el proceso utilizado para crear software. La programación y el mantenimiento del código fuente es el paso central de e...Control de versionesControl de versionesEl control de versiones (también conocido como control de revisión , control de código fuente y gestión de código fuente ) es la práctica de ingeni...Código baseCódigo baseEn el desarrollo de software , una base de código (o código base ) es una colección de código fuente que se utiliza para crear un sistema de softwa...Ramificación (control de versiones)Ramificación (control de versiones)La ramificación , en el control de versiones y la gestión de la configuración de software , es la duplicación de un objeto bajo control de versione...GitGitGit ( / ɡ ɪ t / ) [8] es un sistema de control de versiones distribuido [9] que rastrea las versiones de los archivos . Los programadores que desar...De igual a igualUna red peer-to-peer (P2P) en la que nodos interconectados ("pares") comparten recursos entre sí sin el uso de un sistema administrativo centraliza...