stringtranslate.com

Control de versiones

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.

Descripción general

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 solució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]

Historia

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 gestión de fuentes y control de versiones 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]

Estructura

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.

Estructura gráfica

Ejemplo de gráfico de historial de un proyecto controlado por revisiones; el tronco está en verde, las ramas en amarillo y el gráfico no es un árbol debido a la presencia de fusiones (las flechas rojas).

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, "á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 revisiones. 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.

Estrategias especializadas

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.

En los negocios y el derecho

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 ]

Modelos de gestión de fuentes

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.

Operaciones atómicas

Una operación es atómica si el sistema se mantiene en un estado consistente incluso si se interrumpe la operación. 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]

Bloqueo de archivos

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.

Fusión de versiones

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 en absoluto. 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.

Líneas base, etiquetas y rótulos

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 .

Control de revisión distribuido

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.

Mejores prácticas

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.

Costos y beneficios

Los costos y beneficios varían según la herramienta de control de versiones elegida y el campo en el que se aplique. Esta sección se refiere al campo del desarrollo de software, donde el control de versiones se aplica ampliamente.

Costos

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 un beneficio útil.

Beneficios

Permite revertir cambios

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 simplifica la implementación, el mantenimiento y el desarrollo.

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]

Mitigación de daños, rendición de cuentas y mejora de procesos y diseño

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]

Simplifica la depuración

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.

Mejora la colaboración y la comunicación.

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.

Integración

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.

Entorno de desarrollo integrado

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 avanzada generan mensajes de confirmación apropiados. [22]

Terminología común

La terminología puede variar de un sistema a otro, pero algunos términos de uso común incluyen: [23]

Base

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.

Culpa

Una búsqueda del autor y la revisión que modificó por última vez una línea en particular.

Rama

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.

Cambiar

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 un cambio varía entre los sistemas de control de versiones.

Lista de cambios

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.

Verificar

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.

Clon

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.

Comprometerse (sustantivo)

En el software de control de versiones, un conjunto de cambios (también conocido como commit [24] y revisión [25] [26] ) es un conjunto de modificaciones empaquetadas juntas, junto con metainformación sobre las modificaciones. Un conjunto de cambios describe las diferencias exactas entre dos versiones sucesivas en el repositorio de cambios del sistema de control de versiones. Los sistemas de control de versiones suelen tratar los conjuntos de cambios como una unidad atómica , un conjunto indivisible. Este es un modelo de sincronización . [27] [28]

Comprometerse (verbo)

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.

Mensaje de confirmación

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.

Conflicto

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.

Compresión delta

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.

Flujo dinámico

Un flujo en el que algunas o todas las versiones de archivos son espejos de las versiones del flujo principal.

Exportar

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.

Buscar

Ver tirar .

Integración hacia adelante

El proceso de fusionar los cambios realizados en el tronco principal en una rama de desarrollo (característica o equipo).

Cabeza

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

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.

Inicializar

Para crear un repositorio nuevo y vacío.

Deltas entrelazados

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 .

Etiqueta

Ver etiqueta .

Cierre

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 ).

Chutarse

Similar al tronco , pero puede haber una línea principal para cada rama.

Unir

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:

Promover

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]

Tirar, empujar

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 .

Solicitud de extracció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 al responsable del proyecto que 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.

Repositorio

En los sistemas de control de versiones, un repositorio es una estructura de datos que almacena metadatos para un conjunto de archivos o una estructura de directorios . [36] Dependiendo de si el sistema de control de versiones en uso es distribuido, como Git o Mercurial , o centralizado, como Subversion , CVS o Perforce , todo el conjunto de información en el repositorio puede estar duplicado en el sistema de cada usuario o puede mantenerse en un solo servidor . [37] Algunos de los metadatos que contiene un repositorio incluyen, entre otras cosas, un registro histórico de cambios en el repositorio, un conjunto de objetos de confirmación y un conjunto de referencias a objetos de confirmación, llamados encabezados .

Resolver

El acto de intervención del usuario para abordar un conflicto entre diferentes cambios en el mismo documento.

Integración inversa

El proceso de fusionar diferentes ramas del equipo en el tronco principal del sistema de versiones.

Revisión y versión

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.

Compartir

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.

Arroyo

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.

Etiqueta

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.

Trompa

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] )

Actualizar

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)

Desbloqueo

Liberando un bloqueo.

Copia de trabajo

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 .

Véase también

Notas

  1. ^ En este caso, los buffers de edición son una forma secundaria de copia de trabajo y no se los denomina como tales.
  2. ^ En principio, dos revisiones pueden tener la misma marca de tiempo y, por lo tanto, no pueden ordenarse en una línea. Esto suele ocurrir en el caso de repositorios separados, aunque también es posible que se produzcan cambios simultáneos en varias ramas de un único repositorio. En estos casos, las revisiones pueden considerarse como un conjunto de líneas separadas, una por repositorio o rama (o rama dentro de un repositorio).
  3. ^ El "árbol" de revisiones o repositorio no debe confundirse con el árbol de directorios de archivos en una copia de trabajo.
  4. ^ Si una nueva rama se basa en HEAD, entonces topológicamente HEAD ya no es una punta, ya que tiene un hijo.
  5. ^ "Línea principal" también puede referirse a la ruta principal en una rama separada.

Referencias

  1. ^ abc O'Sullivan, Bryan (2009). Mercurial: la guía definitiva. Sebastopol: O'Reilly Media, Inc. ISBN 978-0-596-55547-4Archivado desde el original el 8 de diciembre de 2019 . Consultado el 4 de septiembre de 2015 .
  2. ^ " Google Docs ", Ver qué ha cambiado en un archivo, Google Inc., archivado desde el original el 2022-10-06 , consultado el 2021-04-21.
  3. ^ Scott, Chacon; Straub, Ben (2014). Pro Git Second Edition. Estados Unidos: Apress . p. 14. Archivado desde el original el 25 de diciembre de 2015 . Consultado el 19 de febrero de 2022 .
  4. ^ Goetz, Martin (3 de mayo de 2002). "An Interview with Martin Goetz" (Entrevista). Entrevista realizada por Jeffrey R. Yost. Washington, DC: Instituto Charles Babbage, Universidad de Minnesota. pp. 5–7. Archivado desde el original el 26 de septiembre de 2024. Consultado el 17 de agosto de 2023 .
  5. ^ Piscipo, Joseph (3 de mayo de 2002). "An Interview with Joseph Piscopo" (Entrevista). Entrevista realizada por Thomas Haigh. Washington, DC: Instituto Charles Babbage, Universidad de Minnesota. pp. 3, 5, 12–13. Archivado desde el original el 26 de septiembre de 2024. Consultado el 17 de agosto de 2023 .
  6. ^ Rochkind, Marc J. (1975). "El sistema de control del código fuente" (PDF) . IEEE Transactions on Software Engineering . SE-1 (4): 364–370. doi :10.1109/TSE.1975.6312866. S2CID  10006076.
  7. ^ Tichy, Walter F. (1985). "Rcs — un sistema para el control de versiones". Software: práctica y experiencia . 15 (7): 637–654. doi :10.1002/spe.4380150703. ISSN  0038-0644. S2CID  2605086. Archivado desde el original el 2024-09-26 . Consultado el 2023-12-28 .
  8. ^ Collins-Sussman, Ben; Fitzpatrick, BW; Pilato, CM (2004), Control de versiones con Subversion , O'Reilly, ISBN 0-596-00448-6
  9. ^ Loeliger, Jon; McCullough, Matthew (2012). Control de versiones con Git: potentes herramientas y técnicas para el desarrollo colaborativo de software. O'Reilly Media. pp. 2–5. ISBN 978-1-4493-4504-4Archivado desde el original el 26 de septiembre de 2024. Consultado el 22 de marzo de 2023 .
  10. ^ Para dibujos de ingeniería, véase Whiteprint#Control de documentos , para algunos de los sistemas manuales implementados en el siglo XX, por ejemplo, los Procedimientos de ingeniería de Hughes Aircraft , cada revisión de los cuales requería la aprobación de Lawrence A. Hyland ; véanse también los procedimientos de aprobación instituidos por el gobierno de los EE. UU.
  11. ^ Smart, John Ferguson (2008). Herramientas de potencia de Java. "O'Reilly Media, Inc.", pág. 301. ISBN 978-1-4919-5454-6Archivado desde el original el 26 de septiembre de 2024 . Consultado el 20 de julio de 2019 .
  12. ^ Wheeler, David. «Comentarios sobre sistemas de gestión de configuración de software (SCM) de software libre/software de código abierto (OSS/FS)». Archivado desde el original el 9 de noviembre de 2020. Consultado el 8 de mayo de 2007 .
  13. ^ GitLab. "¿Cuáles son las mejores prácticas de control de versiones de Git?". gitlab.com . Consultado el 11 de noviembre de 2022 .
  14. ^ Alessandro Picarelli (17 de noviembre de 2020). "El costo de no usar el control de versiones". Archivado desde el original el 19 de noviembre de 2022. Consultado el 18 de noviembre de 2022. En términos de horas de trabajo , 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.
  15. ^ Irma Azarian (14 de junio de 2023). "Una revisión del control de versiones de software: sistemas, beneficios y por qué es importante". Archivado desde el original el 26 de septiembre de 2024. Consultado el 18 de noviembre de 2022. Los 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.
  16. ^ ReQtest (2020-10-26). "¿Cuáles son los beneficios del control de versiones?". Archivado desde el original el 2022-11-22 . Consultado el 2022-11-21 . 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.
  17. ^ Chiradeep BasuMallick (6 de octubre de 2022). "¿Qué es el control de versiones? Significado, herramientas y ventajas". Archivado desde el original el 19 de noviembre de 2022. Consultado el 18 de noviembre de 2022. Los equipos de software pueden comprender la evolución de una solución examinando versiones anteriores a través de revisiones de código.
  18. ^ Chiradeep BasuMallick (6 de octubre de 2022). "¿Qué es el control de versiones? Significado, herramientas y ventajas". Archivado desde el original el 19 de noviembre de 2022. Consultado el 18 de noviembre de 2022. Si se comete un error, los desarrolladores pueden retroceder en el tiempo y revisar iteraciones anteriores del código para corregir el error y minimizar las molestias para todos los miembros del equipo.
  19. ^ Chacon, Scott; Straub, Ben (3 de octubre de 2022). "Pro Git" (versión 2.1.395-2-g27002dd ed.). Apress. Archivado desde el original el 26 de septiembre de 2024. Consultado el 18 de noviembre de 2022. La 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.
  20. ^ Irma Azarian (14 de junio de 2023). "Una revisión del control de versiones de software: sistemas, beneficios y por qué es importante". Archivado desde el original el 26 de septiembre de 2024. Consultado el 18 de noviembre de 2022. El 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.
  21. ^ Jesse Phillips (2019-01-21) [2018-12-12]. "Git es una herramienta de comunicación". Archivado desde el original el 2022-11-19 . Consultado el 2022-11-18 . Hay discusiones continuas sobre el uso de rebase, merge y/o squash. Quiero centrarme en el punto de todas estas opciones: la comunicación.
  22. ^ Cortes-Coy, Luis Fernando; Linares-Vasquez, Mario; Aponte, Jairo; Poshyvanyk, Denys (2014). "Sobre la generación automática de mensajes de confirmación mediante el resumen de los cambios en el código fuente". 2014 IEEE 14th International Working Conference on Source Code Analysis and Manipulation . IEEE. págs. 275–284. doi :10.1109/scam.2014.14. ISBN. 978-1-4799-6148-1.S2CID360545  .​
  23. ^ Wingerd, Laura (2005). Practical Perforce. O'Reilly. ISBN 0-596-10185-6Archivado desde el original el 21 de diciembre de 2007. Consultado el 27 de agosto de 2006 .
  24. ^ conjunto de cambios en el glosario de git
  25. ^ revisión en el gitglossary
  26. ^ Entendiendo a Mercurial - Mercurial
  27. ^ Mercurial: ChangeSet Archivado el 15 de enero de 2010 en Wayback Machine.
  28. ^ "Comparación de sistemas de control de versiones". Better SCM Initiative. Archivado desde el original el 21 de marzo de 2009.
  29. ^ Gregory, Gary (3 de febrero de 2011). "Trunk vs. HEAD en sistemas de control de versiones". Java, Eclipse y otras curiosidades tecnológicas . Archivado desde el original el 20 de septiembre de 2020. Consultado el 16 de diciembre de 2012 .
  30. ^ Collins-Sussman, Fitzpatrick y Pilato 2004, 1.5: Resolución del ciclo de recorrido de SVN: 'La G significa merGed, lo que significa que el archivo tuvo cambios locales para empezar, pero los cambios que vinieron del repositorio no se superpusieron con los cambios locales.'
  31. ^ Manual de conceptos (versión 4.7). Accurev. Julio de 2008.
  32. ^ Sijbrandij, Sytse (29 de septiembre de 2014). "Flujo de GitLab". GitLab . Consultado el 4 de agosto de 2018 .
  33. ^ ab Johnson, Mark (8 de noviembre de 2013). "¿Qué es una solicitud de incorporación de cambios?". Oaawatch . Consultado el 27 de marzo de 2016 .
  34. ^ "Uso de solicitudes de incorporación de cambios". GitHub . Consultado el 27 de marzo de 2016 .
  35. ^ "Realizar una solicitud de incorporación de cambios". Atlassian . Consultado el 27 de marzo de 2016 .
  36. ^ "SVNBook" . Consultado el 20 de abril de 2012 .
  37. ^ "Conceptos y mejores prácticas de control de versiones". 2018-03-03. Archivado desde el original el 2020-04-27 . Consultado el 2020-07-10 .
  38. ^ Wallen, Jack (22 de septiembre de 2020). "GitHub reemplazará master por main a partir de octubre: qué deben hacer ahora los desarrolladores". TechRepublic . Archivado desde el original el 8 de febrero de 2021 . Consultado el 24 de abril de 2022 .
  39. ^ Heinze, Carolyn (24 de noviembre de 2020). «Por qué GitHub cambió el nombre de su rama maestra a principal». TheServerSide . Archivado desde el original el 26 de mayo de 2022 . Consultado el 24 de abril de 2022 .

Enlaces externos