El 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 ingeniería de software de controlar, organizar y rastrear diferentes versiones en el historial de archivos de computadora ; principalmente archivos de texto de código fuente , pero generalmente cualquier tipo de archivo.
El control de versiones es un componente de la gestión de la configuración del software . [1]
Un sistema de control de versiones es una herramienta de software que automatiza el control de versiones. Alternativamente, el control de versiones está integrado como una característica de algunos sistemas como procesadores de texto , hojas de cálculo , documentos web colaborativos [2] y sistemas de gestión de contenido , por ejemplo, el historial de páginas de Wikipedia .
El control de versiones incluye la visualización de versiones antiguas y permite revertir un archivo a una versión anterior.
A medida que los equipos desarrollan software, es común que se implementen múltiples versiones del mismo software en diferentes sitios y que los desarrolladores trabajen simultáneamente en actualizaciones. Los errores o las características del software a menudo solo están presentes en ciertas versiones (debido a la corrección de algunos problemas y la introducción de otros a medida que se desarrolla el programa). Por lo tanto, para localizar y corregir errores, es de vital importancia poder recuperar y ejecutar diferentes versiones del software para determinar en qué versión(es) ocurre el problema. También puede ser necesario desarrollar dos versiones del software simultáneamente: por ejemplo, cuando una versión tiene errores corregidos, pero no nuevas características ( rama ), mientras que la otra versión es donde se trabaja en nuevas características ( tronco ).
En el nivel más simple, los desarrolladores podrían simplemente conservar múltiples copias de las diferentes versiones del programa y etiquetarlas apropiadamente. Este enfoque simple se ha utilizado en muchos proyectos de software de gran envergadura. Si bien este método puede funcionar, es ineficiente ya que se deben mantener muchas copias casi idénticas del programa. Esto requiere mucha autodisciplina por parte de los desarrolladores y a menudo conduce a errores. Dado que la base de código es la misma, también requiere otorgar permiso de lectura, escritura y ejecución a un grupo de desarrolladores, y esto agrega la presión de alguien que administra los permisos para que la base de código no se vea comprometida, lo que agrega más complejidad. En consecuencia, se han desarrollado sistemas para automatizar parte o la totalidad del proceso de control de versiones. Esto garantiza que la mayoría de los pasos de administración de control de versiones estén ocultos detrás de escena.
Además, en el desarrollo de software, la práctica legal y comercial y otros entornos, cada vez es más común que un solo documento o fragmento de código sea editado por un equipo, cuyos miembros pueden estar dispersos geográficamente y perseguir intereses diferentes e incluso opuestos. Un control de revisión sofisticado que rastree y registre la propiedad de los cambios en los documentos y el código puede ser extremadamente útil o incluso indispensable en tales situaciones.
El control de revisión también puede realizar un seguimiento de los cambios en los archivos de configuración , como los que se almacenan normalmente en /etclos /usr/local/etcsistemas Unix . Esto ofrece a los administradores de sistemas otra forma de realizar un seguimiento sencillo de los cambios realizados y una forma de volver a versiones anteriores en caso de que sea necesario.
Muchos sistemas de control de versiones identifican la versión de un archivo como un número o letra, denominado número de versión , versión , número de revisión , revisión o nivel de revisión . Por ejemplo, la primera versión de un archivo puede ser la versión 1. Cuando se modifica el archivo, la siguiente versión es la 2. Cada versión está asociada a una marca de tiempo y a la persona que realiza el cambio. Las revisiones se pueden comparar, restaurar y, con algunos tipos de archivos, fusionar. [3]
La herramienta de actualización de software IEBUPDTE para OS/360 de IBM data de 1962 y podría decirse que fue una precursora de las herramientas de control de versiones. Dos paquetes de control de versiones y administración de fuentes que se usaban mucho en las instalaciones de IBM 360/370 eran The Librarian y Panvalet . [4] [5]
En 1972 se inició un sistema completo diseñado para el control del código fuente, Source Code Control System para el mismo sistema (OS/360). La introducción de Source Code Control System, publicada el 4 de diciembre de 1975, implicó históricamente que fue el primer sistema de control de revisión deliberado. [6] RCS siguió justo después, [7] con su versión en red Concurrent Versions System . La siguiente generación después de Concurrent Versions System estuvo dominada por Subversion , [8] seguida por el surgimiento de herramientas de control de revisión distribuidas como Git . [9]
El control de revisión gestiona los cambios que se producen en un conjunto de datos a lo largo del tiempo. Estos cambios pueden estructurarse de diversas maneras.
A menudo, se piensa en los datos como una colección de muchos elementos individuales, como archivos o documentos, y se hace un seguimiento de los cambios en los archivos individuales. Esto concuerda con las intuiciones sobre los archivos separados, pero causa problemas cuando cambia la identidad, como durante el cambio de nombre, la división o la fusión de archivos. En consecuencia, algunos sistemas como Git , en cambio, consideran los cambios en los datos como un todo, lo que es menos intuitivo para cambios simples, pero simplifica los cambios más complejos.
Cuando se modifican datos que están bajo control de revisión, después de ser recuperados mediante el proceso de desprotección, esto no se refleja en general inmediatamente en el sistema de control de revisión (en el repositorio ), sino que debe ser registrado o confirmado. Una copia fuera del control de revisión se conoce como "copia de trabajo". Como ejemplo simple, cuando se edita un archivo de computadora, los datos almacenados en la memoria por el programa de edición son la copia de trabajo, que se confirma al guardarlo. Concretamente, uno puede imprimir un documento, editarlo a mano y solo más tarde ingresar manualmente los cambios en una computadora y guardarlo. Para el control del código fuente, la copia de trabajo es en cambio una copia de todos los archivos en una revisión particular, generalmente almacenada localmente en la computadora del desarrollador; [nota 1] en este caso, guardar el archivo solo cambia la copia de trabajo, y el registro en el repositorio es un paso separado.
Si varias personas trabajan en un único conjunto de datos o documento, implícitamente crean ramas de los datos (en sus copias de trabajo) y, por lo tanto, surgen problemas de fusión, como se explica a continuación. Para la edición colaborativa de documentos, esto se puede evitar mediante el bloqueo de archivos o simplemente evitando trabajar en el mismo documento en el que está trabajando otra persona.
Los sistemas de control de revisión suelen estar centralizados, con un único almacén de datos autorizado, el repositorio, y las extracciones y los registros se realizan con referencia a este repositorio central. Por otra parte, en el control de revisión distribuido , ningún repositorio es autorizado y los datos se pueden extraer y registrar en cualquier repositorio. Cuando se registran en un repositorio diferente, esto se interpreta como una fusión o un parche.
En términos de teoría de grafos , las revisiones se consideran generalmente como una línea de desarrollo (el tronco ) con ramas que se desprenden de este, formando un árbol dirigido, visualizado como una o más líneas de desarrollo paralelas (las "líneas principales" de las ramas) que se ramifican a partir de un tronco. En realidad, la estructura es más complicada, formando un grafo acíclico dirigido , pero para muchos propósitos, un "árbol con fusiones" es una aproximación adecuada.
Las revisiones se producen en secuencia a lo largo del tiempo y, por lo tanto, se pueden organizar en orden, ya sea por número de revisión o marca de tiempo. [nota 2] Las revisiones se basan en revisiones pasadas, aunque es posible reemplazar en gran parte o por completo una revisión anterior, como "eliminar todo el texto existente, insertar texto nuevo". En el caso más simple, sin ramificaciones ni deshacer, cada revisión se basa solo en su predecesora inmediata y forman una línea simple, con una única versión más reciente, la revisión "HEAD" o tip . En términos de teoría de grafos , dibujar cada revisión como un punto y cada relación de "revisión derivada" como una flecha (que convencionalmente apunta de la más antigua a la más nueva, en la misma dirección que el tiempo), es un grafo lineal . Si hay ramificaciones, por lo que múltiples revisiones futuras se basan en una revisión pasada, o deshacer, por lo que una revisión puede depender de una revisión más antigua que su predecesora inmediata, entonces el grafo resultante es en cambio un árbol dirigido (cada nodo puede tener más de un hijo) y tiene múltiples tips, correspondientes a las revisiones sin hijos ("última revisión en cada rama"). [nota 3] En principio, el árbol resultante no necesita tener una punta preferida (la última revisión "principal"), solo varias revisiones diferentes, pero en la práctica una punta generalmente se identifica como HEAD. Cuando una nueva revisión se basa en HEAD, se identifica como la nueva HEAD o se considera una nueva rama. [nota 4] La lista de revisiones desde el inicio hasta HEAD (en términos de teoría de grafos, la ruta única en el árbol, que forma un grafo lineal como antes) es el tronco o línea principal. [nota 5] Por el contrario, cuando una revisión puede basarse en más de una revisión anterior (cuando un nodo puede tener más de un padre ), el proceso resultante se llama fusión y es uno de los aspectos más complejos del control de revisión. Esto ocurre con mayor frecuencia cuando los cambios ocurren en múltiples ramas (generalmente dos, pero son posibles más), que luego se fusionan en una sola rama que incorpora ambos cambios. Si estos cambios se superponen, puede ser difícil o imposible fusionarlos y requerir intervención manual o reescritura.
En presencia de fusiones, el grafo resultante ya no es un árbol, ya que los nodos pueden tener varios padres, sino que es un grafo acíclico dirigido (DAG) con raíz. El grafo es acíclico ya que los padres siempre están hacia atrás en el tiempo y tiene raíz porque hay una versión más antigua. Suponiendo que hay un tronco, las fusiones desde las ramas pueden considerarse como "externas" al árbol: los cambios en la rama se empaquetan como un parche, que se aplica a HEAD (del tronco), creando una nueva revisión sin ninguna referencia explícita a la rama y preservando la estructura del árbol. Por lo tanto, si bien las relaciones reales entre las versiones forman un DAG, este puede considerarse un árbol más fusiones, y el tronco en sí es una línea.
En el control de revisión distribuido, en presencia de múltiples repositorios, estos pueden basarse en una única versión original (una raíz del árbol), pero no es necesario que haya una raíz original; en su lugar, puede haber una raíz separada (la revisión más antigua) para cada repositorio. Esto puede suceder, por ejemplo, si dos personas comienzan a trabajar en un proyecto por separado. De manera similar, en presencia de múltiples conjuntos de datos (múltiples proyectos) que intercambian datos o se fusionan, no hay una única raíz, aunque para simplificar, se puede pensar en un proyecto como principal y el otro como secundario, fusionados en el primero con o sin su propio historial de revisiones.
El control de revisión de ingeniería se desarrolló a partir de procesos formalizados basados en el seguimiento de las revisiones de los primeros planos o líneas azules [ cita requerida ] . Este sistema de control implícitamente permitía volver a un estado anterior del diseño, para los casos en los que se llegaba a un punto muerto de ingeniería en el desarrollo del diseño. Se utilizó una tabla de revisión para realizar un seguimiento de los cambios realizados. Además, las áreas modificadas del dibujo se resaltaron mediante nubes de revisión.
El control de versiones está muy extendido en los ámbitos empresarial y jurídico. De hecho, la "revisión de contratos" y la "revisión legal" son algunas de las primeras formas de control de versiones, [10] y todavía se emplean en los ámbitos empresarial y jurídico con distintos grados de sofisticación. Las técnicas más sofisticadas están empezando a utilizarse para el seguimiento electrónico de los cambios en los archivos CAD (véase gestión de datos de productos ), sustituyendo a la implementación electrónica "manual" del control de versiones tradicional. [ cita requerida ]
Los sistemas de control de revisión tradicionales utilizan un modelo centralizado en el que todas las funciones de control de revisión se llevan a cabo en un servidor compartido . Si dos desarrolladores intentan cambiar el mismo archivo al mismo tiempo, sin algún método para gestionar el acceso, los desarrolladores pueden terminar sobrescribiendo el trabajo del otro. Los sistemas de control de revisión centralizados resuelven este problema en uno de dos "modelos de gestión de fuentes" diferentes: bloqueo de archivos y fusión de versiones.
Una operación es atómica si el sistema se mantiene en un estado consistente incluso si la operación se interrumpe. La operación de confirmación suele ser la más crítica en este sentido. Las confirmaciones indican al sistema de control de revisión que haga que un grupo de cambios sea definitivo y esté disponible para todos los usuarios. No todos los sistemas de control de revisión tienen confirmaciones atómicas; el sistema de versiones concurrentes carece de esta característica. [11]
El método más simple para prevenir problemas de " acceso concurrente " consiste en bloquear los archivos de modo que sólo un desarrollador a la vez tenga acceso de escritura a las copias del " repositorio " central de esos archivos. Una vez que un desarrollador "extrae" un archivo, otros pueden leerlo, pero nadie más puede modificarlo hasta que ese desarrollador "incorpore" la versión actualizada (o cancele la extracción).
El bloqueo de archivos tiene ventajas y desventajas. Puede brindar cierta protección contra conflictos de fusión difíciles cuando un usuario realiza cambios radicales en muchas secciones de un archivo grande (o grupo de archivos). Si los archivos se dejan bloqueados exclusivamente durante demasiado tiempo, otros desarrolladores pueden verse tentados a pasar por alto el software de control de revisión y cambiar los archivos localmente, lo que obliga a una fusión manual difícil cuando finalmente se hayan registrado los demás cambios. En una organización grande, los archivos se pueden dejar "desprotegidos" y bloqueados y olvidarse de ellos a medida que los desarrolladores se mueven entre proyectos: estas herramientas pueden facilitar o no ver quién tiene un archivo desprotegido.
La mayoría de los sistemas de control de versiones permiten que varios desarrolladores editen el mismo archivo al mismo tiempo. El primer desarrollador que "registre" los cambios en el repositorio central siempre tendrá éxito. El sistema puede proporcionar funciones para fusionar cambios posteriores en el repositorio central y conservar los cambios del primer desarrollador cuando otros desarrolladores los registren.
La fusión de dos archivos puede ser una operación muy delicada y, por lo general, solo es posible si la estructura de los datos es sencilla, como en el caso de los archivos de texto . El resultado de la fusión de dos archivos de imagen puede no generar un archivo de imagen. El segundo desarrollador que registre el código deberá tener cuidado con la fusión para asegurarse de que los cambios sean compatibles y de que la operación de fusión no introduzca sus propios errores lógicos en los archivos. Estos problemas limitan la disponibilidad de operaciones de fusión automáticas o semiautomáticas principalmente a documentos simples basados en texto, a menos que haya un complemento de fusión específico disponible para los tipos de archivo.
El concepto de edición reservada puede proporcionar un medio opcional para bloquear explícitamente un archivo para acceso de escritura exclusivo, incluso cuando existe una capacidad de fusión.
La mayoría de las herramientas de control de revisión utilizarán solo uno de estos términos similares (línea base, etiqueta, rótulo) para referirse a la acción de identificar una instantánea ("etiquetar el proyecto") o el registro de la instantánea ("probarlo con la línea base X "). Normalmente, solo se utiliza uno de los términos línea base , etiqueta o rótulo en la documentación o discusión [ cita requerida ] ; pueden considerarse sinónimos.
En la mayoría de los proyectos, algunas instantáneas son más significativas que otras, como aquellas que se utilizan para indicar versiones publicadas, ramas o hitos.
Cuando tanto el término línea base como el de etiqueta o rótulo se utilizan juntos en el mismo contexto, etiqueta y rótulo generalmente se refieren al mecanismo dentro de la herramienta para identificar o hacer el registro de la instantánea, y línea base indica la mayor importancia de cualquier etiqueta o rótulo dado.
La mayoría de las discusiones formales sobre la gestión de la configuración utilizan el término línea base .
Los sistemas de control de revisión distribuidos (DRCS) adoptan un enfoque de igual a igual, en contraposición al enfoque cliente-servidor de los sistemas centralizados. En lugar de un único repositorio central en el que los clientes se sincronizan, la copia de trabajo de cada par del código base es un repositorio auténtico . [12] El control de revisión distribuido lleva a cabo la sincronización mediante el intercambio de parches (conjuntos de cambios) de igual a igual. Esto da lugar a algunas diferencias importantes con respecto a un sistema centralizado:
Más bien, la comunicación sólo es necesaria cuando se impulsan o se extraen cambios de o hacia otros pares.
Para obtener todos los beneficios del control de versiones, es necesario seguir las mejores prácticas. Estas pueden variar según la herramienta de control de versiones y el campo al que se aplica el control de versiones. Las mejores prácticas generalmente aceptadas en el desarrollo de software incluyen: realizar cambios pequeños e incrementales; realizar confirmaciones que impliquen solo una tarea o corrección (un corolario de esto es confirmar solo el código que funciona y que no rompe deliberadamente la funcionalidad existente); utilizar ramificaciones para completar la funcionalidad antes del lanzamiento; escribir mensajes de confirmación claros y descriptivos, dejar claro qué, por qué y cómo en la descripción de la confirmación o en el código; y utilizar una estrategia de ramificación consistente. [13] Otras mejores prácticas de desarrollo de software, como la revisión de código y las pruebas de regresión automatizadas , pueden ayudar a seguir las mejores prácticas de control de versiones.
Los costos y beneficios varían según la herramienta de control de versiones elegida y el campo en el que se aplica. Esta sección se refiere al campo del desarrollo de software, donde el control de versiones se aplica ampliamente.
Además de los costos de licencia del software de control de versiones, su uso requiere tiempo y esfuerzo. Es necesario comprender los conceptos subyacentes al control de versiones y aprender los detalles técnicos necesarios para operar el software de control de versiones elegido. Es necesario aprender las mejores prácticas de control de versiones e integrarlas en las prácticas de desarrollo de software existentes de la organización. Es posible que se requiera un esfuerzo de la gerencia para mantener la disciplina necesaria para seguir las mejores prácticas a fin de obtener beneficios útiles.
Una ventaja fundamental es la capacidad de mantener un historial y revertir los cambios, lo que permite al desarrollador deshacer los cambios fácilmente. Esto le da al desarrollador más oportunidades de experimentar, eliminando el miedo a romper el código existente. [14]
La ramificación facilita la implementación. La ramificación y la fusión, la producción, el empaquetado y el etiquetado de parches de código fuente y la fácil aplicación de parches a bases de código simplifican el mantenimiento y el desarrollo simultáneo de las múltiples bases de código asociadas con las distintas etapas del proceso de implementación: desarrollo, prueba, preparación, producción, etc. [15]
Puede haber mitigación de daños, rendición de cuentas, mejora de procesos y diseño y otros beneficios asociados con el mantenimiento de registros proporcionado por el control de versiones, el seguimiento de quién hizo qué, cuándo, por qué y cómo. [16]
Cuando surgen errores, saber qué se hizo en cada caso ayuda a mitigar los daños y a recuperarse, ya que ayuda a identificar qué problemas existen, cuánto tiempo han existido y a determinar el alcance del problema y las soluciones. [17] Se pueden instalar y probar versiones anteriores para verificar las conclusiones alcanzadas mediante el examen del código y los mensajes de confirmación. [18]
El control de versiones puede simplificar enormemente la depuración. La aplicación de un caso de prueba a múltiples versiones puede identificar rápidamente el cambio que introdujo un error. [19] El desarrollador no necesita estar familiarizado con toda la base de código y puede centrarse en el código que introdujo el problema.
El control de versiones mejora la colaboración de múltiples maneras. Dado que el control de versiones puede identificar cambios conflictivos, es decir, cambios incompatibles realizados en las mismas líneas de código, hay menos necesidad de coordinación entre desarrolladores. [20]
La creación de paquetes de confirmaciones, ramas y todos los mensajes de confirmación y etiquetas de versión asociados mejora la comunicación entre desarrolladores, tanto en el momento como a lo largo del tiempo. [21] Una mejor comunicación, ya sea instantánea o diferida, puede mejorar el proceso de revisión de código, el proceso de prueba y otros aspectos críticos del proceso de desarrollo de software.
Algunas de las herramientas de control de revisiones más avanzadas ofrecen muchas otras facilidades, permitiendo una integración más profunda con otras herramientas y procesos de ingeniería de software.
A menudo, hay complementos disponibles para IDE como Oracle JDeveloper , IntelliJ IDEA , Eclipse , Visual Studio , Delphi , NetBeans IDE , Xcode y GNU Emacs (a través de vc.el). Los prototipos de investigación avanzados generan mensajes de confirmación apropiados. [22]
La terminología puede variar de un sistema a otro, pero algunos términos de uso común incluyen: [23]
Una revisión aprobada de un documento o archivo fuente al que se pueden realizar cambios posteriores. Consulte líneas base, etiquetas y rótulos.
Una búsqueda del autor y la revisión que modificó por última vez una línea en particular.
Un conjunto de archivos bajo control de versiones puede ramificarse o bifurcarse en un momento determinado de modo que, a partir de ese momento, dos copias de esos archivos puedan desarrollarse a diferentes velocidades o de diferentes maneras, independientemente una de la otra.
Un cambio (o diff o delta ) representa una modificación específica de un documento bajo control de versiones. La granularidad de la modificación considerada como cambio varía entre los sistemas de control de versiones.
En muchos sistemas de control de versiones con confirmaciones atómicas de múltiples cambios, una lista de cambios (o CL ), un conjunto de cambios , una actualización o un parche identifican el conjunto de cambios realizados en una única confirmación. Esto también puede representar una vista secuencial del código fuente, lo que permite examinar el código fuente a partir de cualquier ID de lista de cambios en particular.
Realizar un check out (o co ) es crear una copia de trabajo local desde el repositorio. Un usuario puede especificar una revisión específica u obtener la última. El término "check out" también se puede utilizar como sustantivo para describir la copia de trabajo. Cuando se ha realizado un check out de un servidor de archivos compartido, otros usuarios no pueden editarlo. Piense en ello como en un hotel: cuando realiza el check out, ya no tiene acceso a sus servicios.
Clonar significa crear un repositorio que contenga las revisiones de otro repositorio. Esto es equivalente a insertar o extraer un repositorio vacío (recién inicializado). Como sustantivo, se puede decir que dos repositorios son clones si se mantienen sincronizados y contienen las mismas revisiones.
Confirmar ( check in , ci o, más raramente, install , submission o record ) es escribir o fusionar los cambios realizados en la copia de trabajo en el repositorio. Una confirmación contiene metadatos, generalmente la información del autor y un mensaje de confirmación que describe el cambio.
Una nota breve, escrita por el desarrollador, almacenada con la confirmación, que describe la confirmación. Lo ideal es que registre por qué se realizó la modificación, una descripción del efecto o propósito de la modificación y aspectos no obvios de cómo funciona el cambio.
Se produce un conflicto cuando distintas partes realizan cambios en el mismo documento y el sistema no puede conciliarlos. El usuario debe resolver el conflicto combinando los cambios o seleccionando un cambio en lugar del otro.
La mayoría del software de control de versiones utiliza compresión delta , que conserva únicamente las diferencias entre versiones sucesivas de los archivos. Esto permite un almacenamiento más eficiente de muchas versiones diferentes de archivos.
Un flujo en el que algunas o todas las versiones de archivos son espejos de las versiones del flujo principal.
Exportar es el acto de obtener los archivos del repositorio. Es similar a extraerlos, excepto que crea un árbol de directorios limpio sin los metadatos de control de versiones utilizados en una copia de trabajo. Esto se suele utilizar antes de publicar el contenido, por ejemplo.
Ver tirar .
El proceso de fusionar los cambios realizados en el tronco principal en una rama de desarrollo (característica o equipo).
También llamado a veces tip , se refiere a la confirmación más reciente, ya sea al tronco o a una rama. El tronco y cada rama tienen su propio encabezado, aunque a veces se usa HEAD de manera imprecisa para referirse al tronco. [29]
Importar es el acto de copiar un árbol de directorio local (que actualmente no es una copia de trabajo) en el repositorio por primera vez.
Para crear un repositorio nuevo y vacío.
Algunos programas de control de revisión utilizan deltas intercalados , un método que permite almacenar el historial de archivos basados en texto de una manera más eficiente que mediante el uso de compresión delta .
Ver etiqueta .
Cuando un desarrollador bloquea un archivo, nadie más puede actualizarlo hasta que se desbloquee. El bloqueo puede ser posible mediante el sistema de control de versiones o mediante comunicaciones informales entre desarrolladores (también conocido como bloqueo social ).
Similar al tronco , pero puede haber una línea principal para cada rama.
Una fusión o integración es una operación en la que se aplican dos conjuntos de cambios a un archivo o conjunto de archivos. Algunos ejemplos son los siguientes:
El acto de copiar el contenido de un archivo desde una ubicación menos controlada a una ubicación más controlada. Por ejemplo, desde el espacio de trabajo de un usuario a un repositorio, o desde un flujo a su padre. [31]
Copiar revisiones de un repositorio a otro. La extracción la inicia el repositorio receptor, mientras que la inserción la inicia el repositorio de origen. A veces, "fetch" se utiliza como sinónimo de "pull" o para referirse a una extracción seguida de una actualización .
Las contribuciones a un repositorio de código fuente que utiliza un sistema de control de versiones distribuido se realizan habitualmente mediante una solicitud de incorporación de cambios, también conocida como solicitud de fusión. [32] 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 pasar a formar parte de la base de código fuente. [33]
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. [34]
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. [33] [35] 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.El acto de intervención del usuario para abordar un conflicto entre diferentes cambios en el mismo documento.
El proceso de fusionar diferentes ramas del equipo en el tronco principal del sistema de versiones.
Una versión es cualquier cambio de forma. En SVK, una revisión es el estado en un momento determinado de todo el árbol del repositorio.
El acto de hacer que un archivo o carpeta esté disponible en varias ramas al mismo tiempo. Cuando se modifica un archivo compartido en una rama, se modifica también en las demás ramas.
Un contenedor para archivos ramificados que tiene una relación conocida con otros contenedores similares. Los flujos forman una jerarquía; cada flujo puede heredar varias propiedades (como versiones, espacio de nombres, reglas de flujo de trabajo, suscriptores, etc.) de su flujo principal.
Una etiqueta o rótulo hace referencia a una instantánea importante en el tiempo, que se mantiene constante en muchos archivos. En ese momento, todos esos archivos pueden etiquetarse con un nombre o número de revisión significativo y fácil de usar. Consulte líneas base, etiquetas y rótulos.
El tronco es la única línea de desarrollo que no es una rama (a veces también llamada línea base, línea principal o maestra [38] [39] )
Una actualización (o sincronización , pero sincronización también puede significar una combinación de push y pull ) fusiona los cambios realizados en el repositorio (por otras personas, por ejemplo) en la copia de trabajo local . Actualización también es el término utilizado por algunas herramientas de CM (CM+, PLS, SMS) para el concepto de paquete de cambios (consulte lista de cambios ). Sinónimo de checkout en sistemas de control de revisión que requieren que cada repositorio tenga exactamente una copia de trabajo (común en sistemas distribuidos)
Liberando un bloqueo.
La copia de trabajo es la copia local de los archivos de un repositorio, en un momento o revisión específicos. Todo el trabajo realizado en los archivos de un repositorio se realiza inicialmente en una copia de trabajo, de ahí el nombre. Conceptualmente, es un sandbox .
te costará entre 6 y 48 veces más de lo que te hubiera costado usar el control de versiones, y eso es por rebobinar un par de modelos para un solo desarrollador.
sistemas de control de versiones permiten comparar archivos, identificar diferencias y fusionar los cambios si es necesario antes de confirmar cualquier código. El control de versiones también es una excelente manera de realizar un seguimiento de las compilaciones de aplicaciones al poder identificar qué versión se encuentra actualmente en desarrollo, control de calidad y producción.
El historial del documento proporciona información valiosa sobre el autor y la fecha de edición. También brinda información sobre el propósito de los cambios realizados. Tendrá un impacto en el desarrollador que trabaja en la última versión, ya que ayudará a resolver problemas experimentados en versiones anteriores. La capacidad de identificar al autor del documento permite al equipo actual vincular los documentos con colaboradores específicos. Esto, a su vez, permite al equipo actual descubrir patrones que pueden ayudar a corregir errores. Esto ayudará a mejorar la funcionalidad general del software.
Los equipos de software pueden comprender la evolución de una solución examinando versiones anteriores a través de revisiones de código.
Si se comete un error, los desarrolladores pueden retroceder en el tiempo y revisar iteraciones anteriores del código para remediarlo y minimizar las molestias para todos los miembros del equipo.
herramienta git bisect es una herramienta de depuración increíblemente útil que se utiliza para encontrar qué confirmación específica fue la primera en introducir un error o problema haciendo una búsqueda binaria automática.
control de versiones es un proceso invaluable, especialmente cuando hay varios desarrolladores trabajando en una sola aplicación, porque les permite compartir archivos fácilmente. Sin control de versiones, los desarrolladores terminarán pisoteándose unos a otros y sobrescribirán los cambios de código que alguien más puede haber completado sin siquiera darse cuenta. El uso de estos sistemas le permite verificar archivos para ver si hay modificaciones y luego, durante el registro, si otro usuario ha cambiado los archivos, se le avisará y se le permitirá fusionarlos.
Hay discusiones continuas sobre el uso de rebase, merge y/o squash. Quiero centrarme en el punto de todas estas opciones: la comunicación.