En ingeniería de software , el control de versiones (también conocido como control de revisiones , control de fuentes o gestión de código fuente ) es una clase de sistemas responsables de gestionar cambios en programas informáticos , documentos, grandes sitios web u otras colecciones de información. El control de versiones es un componente de la gestión de la configuración del software . [1]
Los cambios generalmente se identifican mediante un código numérico o de letras, denominado "número de revisión", "nivel de revisión" o simplemente "revisión". Por ejemplo, un conjunto inicial de archivos es "revisión 1". Cuando se realiza el primer cambio, el conjunto resultante es "revisión 2", y así sucesivamente. Cada revisió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. [2]
La necesidad de una forma lógica de organizar y controlar las revisiones ha existido casi desde que existe la escritura , pero el control de revisiones se volvió mucho más importante y complicado cuando comenzó la era de la informática. La numeración de las ediciones de libros y las revisiones de especificaciones son ejemplos que se remontan a la era de la imprenta. Hoy en día, los sistemas de control de revisiones más capaces (y complejos) son los que se utilizan en el desarrollo de software , donde un equipo de personas puede realizar cambios simultáneamente en los mismos archivos.
Los sistemas de control de versiones se ejecutan más comúnmente como aplicaciones independientes, pero el control de revisiones también está integrado en varios tipos de software, como procesadores de texto y hojas de cálculo , documentos web colaborativos , [3] y sistemas de gestión de contenidos , por ejemplo, el historial de páginas de Wikipedia . El control de revisiones permite revertir un documento a una revisión anterior, lo cual es fundamental para permitir a los editores realizar un seguimiento de las ediciones de los demás, corregir errores y defenderse contra el vandalismo y el spam en los wikis .
En ingeniería de software , el control de revisiones es cualquier tipo de práctica que rastrea y proporciona control sobre los cambios en el código fuente . Los desarrolladores de software a veces utilizan software de control de revisiones para mantener la documentación y los archivos de configuración , así como el código fuente.
A medida que los equipos diseñan, desarrollan e implementan software, es común que se implementen múltiples versiones del mismo software en diferentes sitios y que los desarrolladores del software trabajen simultáneamente en las actualizaciones. Los errores o 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 ocurre el problema. También puede ser necesario desarrollar dos versiones del software al mismo tiempo: por ejemplo, donde una versión tiene errores corregidos, pero no tiene características nuevas ( rama ), mientras que en la otra versión 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 adecuadamente. Este enfoque simple se ha utilizado en muchos proyectos de software grandes. Si bien este método puede funcionar, es ineficaz ya que es necesario 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 del código es la misma, también requiere otorgar permisos de lectura, escritura y ejecución a un conjunto de desarrolladores, y esto agrega la presión de que alguien administre los permisos para que la base del 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 revisiones. Esto garantiza que la mayor parte de la gestión de los pasos de control de versiones quede oculta entre bastidores.
Además, en el desarrollo de software, en la práctica legal y empresarial y en otros entornos, se ha vuelto cada vez 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 objetivos diferentes e incluso contrarios. intereses. Un control de revisión sofisticado que rastrea y da cuenta de 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 revisiones también puede rastrear cambios en los archivos de configuración , como los que normalmente se almacenan /etcen sistemas Unix . Esto brinda a los administradores del sistema otra forma de rastrear fácilmente los cambios realizados y una forma de retroceder a versiones anteriores en caso de que surja la necesidad./usr/local/etc
La herramienta de actualización de software OS/360 IEBUPDTE de IBM se remonta a 1962 y posiblemente sea una precursora de las herramientas del sistema de control de versiones. Dos paquetes de control de versiones y gestión de código fuente muy utilizados en las instalaciones de IBM 360/370 fueron The Librarian y Panvalet . [4] [5]
En 1972 se inició un sistema completo diseñado para el control del código fuente, el Sistema de control de código fuente para el mismo sistema (OS/360). La introducción del Sistema de control de código fuente, 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 del Sistema de Versiones Concurrentes estuvo dominada por Subversion , [8] seguida por el surgimiento de herramientas de control de revisiones distribuidas como Git . [9]
El control de revisiones gestiona los cambios en un conjunto de datos a lo largo del tiempo. Estos cambios se pueden estructurar de varias maneras.
A menudo, los datos se consideran una colección de muchos elementos individuales, como archivos o documentos, y se realiza un seguimiento de los cambios en archivos individuales. Esto concuerda con las intuiciones sobre archivos separados, pero causa problemas cuando cambia la identidad, como al cambiar el nombre, dividir o fusionar archivos. En consecuencia, algunos sistemas como Git 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 check-out, esto en general no se refleja inmediatamente en el sistema de control de revisión (en el repositorio ), sino que debe registrarse o confirmarse. Una copia fuera del control de revisión se conoce como "copia de trabajo". Como ejemplo simple, al editar 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 guardar. Concretamente, uno puede imprimir un documento, editarlo a mano y sólo después introducir 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 de 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 registrarlo en el repositorio es un paso separado.
Si varias personas están trabajando en un único conjunto de datos o documento, implícitamente están creando ramas de los datos (en sus copias de trabajo) y, por lo tanto, surgen problemas de fusión, como se analiza a continuación. Para la edición colaborativa simple de documentos, esto se puede evitar mediante el bloqueo de archivos o simplemente evitando trabajar en el mismo documento en el que otra persona está trabajando.
Los sistemas de control de revisiones suelen estar centralizados, con un único almacén de datos autorizado, el repositorio y las salidas y entradas realizadas con referencia a este repositorio central. Alternativamente, en el control de revisiones distribuido , ningún repositorio tiene autoridad y los datos se pueden extraer y registrar en cualquier repositorio. Cuando se registra en un repositorio diferente, esto se interpreta como una fusión o un parche.
En términos de teoría de grafos , las revisiones generalmente se consideran como una línea de desarrollo (el tronco ) con ramas que parten 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. de un baúl. En realidad, la estructura es más complicada y forma un gráfico 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 anteriores, aunque es posible reemplazar en gran medida o por completo una revisión anterior, como "eliminar todo el texto existente, insertar texto nuevo". En el caso más simple, sin bifurcaciones ni deshacer, cada revisión se basa únicamente en su predecesora inmediata, y forman una línea simple, con una única versión más reciente, la revisión o consejo "HEAD" . 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 (convencionalmente apuntando de lo más antiguo a lo más nuevo, en la misma dirección que el tiempo), este es un gráfico lineal . Si hay ramificación, por lo que múltiples revisiones futuras se basan en una revisión pasada, o se deshacen, por lo que una revisión puede depender de una revisión anterior a su predecesora inmediata, entonces el gráfico resultante es en cambio un árbol dirigido (cada nodo puede tener más de un child), y tiene múltiples consejos, correspondientes a las revisiones sin hijos ("última revisión en cada rama"). [nota 3] En principio, el árbol resultante no necesita tener una sugerencia preferida (última revisión "principal") – solo varias revisiones diferentes – pero en la práctica una sugerencia generalmente se identifica como HEAD. Cuando una nueva revisión se basa en HEAD, se identifica como el nuevo HEAD o se considera una nueva rama. [nota 4] La lista de revisiones desde el inicio de HEAD (en términos de teoría de grafos, la ruta única en el árbol, que forma un gráfico 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 se producen cambios en varias ramas (la mayoría de las veces dos, pero es posible que haya más), que luego se fusionan en una sola rama que incorpora ambos cambios. Si estos cambios se superponen, puede resultar difícil o imposible fusionarlos y requerir intervención manual o reescritura.
En presencia de fusiones, el gráfico resultante ya no es un árbol, ya que los nodos pueden tener varios padres, sino que es un gráfico acíclico dirigido (DAG) con raíz. El gráfico es acíclico ya que los padres siempre están hacia atrás en el tiempo, y arraigado porque existe una versión más antigua. Suponiendo que hay un tronco, las fusiones de las ramas pueden considerarse "externas" al árbol: los cambios en la rama se empaquetan como un parche, que se aplica al HEAD (del tronco), creando una nueva revisión sin ninguna revisión explícita. referencia a la rama, y preservando la estructura del árbol. Por lo tanto, si bien las relaciones reales entre 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 revisiones 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 uno. repositorio. Esto puede suceder, por ejemplo, si dos personas empiezan 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 existe una raíz única, aunque para simplificar se puede pensar en un proyecto como primario y el otro como secundario, fusionados en el primero con o sin su proyecto. propio historial de revisiones.
Control de revisión de ingeniería desarrollado a partir de procesos formalizados basados en el seguimiento de revisiones de planos o líneas azules iniciales [ cita requerida ] . Este sistema de control permitía implícitamente regresar a un estado anterior del diseño, para los casos en los que se llegaba a un callejón sin salida en 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 negocios y el derecho. De hecho, la "línea roja de contrato" y la "línea negra legal" son algunas de las primeras formas de control de revisión, [10] y todavía se emplean en los negocios y el derecho con diversos grados de sofisticación. Se están empezando a utilizar las técnicas más sofisticadas para el seguimiento electrónico de los cambios en los archivos CAD (ver gestión de datos del producto ), suplantando la implementación electrónica "manual" del control de revisión tradicional. [ cita necesaria ]
Los sistemas de control de revisiones tradicionales utilizan un modelo centralizado donde todas las funciones de control de revisiones 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 administrar el acceso, los desarrolladores pueden terminar sobrescribiendo el trabajo de los demás. Los sistemas de control de revisiones 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 deja 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 le dicen al sistema de control de revisiones que haga que un grupo de cambios sea definitivo y esté disponible para todos los usuarios. No todos los sistemas de control de revisiones tienen confirmaciones atómicas; El sistema de versiones simultáneas carece de esta característica. [11]
El método más simple para prevenir problemas de " acceso concurrente " implica bloquear archivos para 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 "protege" un archivo, otros pueden leerlo, pero nadie más puede cambiarlo hasta que ese desarrollador "protege" la versión actualizada (o cancela la extracción).
El bloqueo de archivos tiene ventajas e inconvenientes. Puede proporcionar 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 omitir el software de control de revisiones y cambiar los archivos localmente, forzando una difícil fusión manual cuando finalmente se registren los otros cambios. En una organización grande, los archivos pueden ser quedan "protegidos" y bloqueados y olvidados a medida que los desarrolladores se mueven entre proyectos; estas herramientas pueden facilitar o no ver quién tiene un archivo protegido.
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 "registra" los cambios en el repositorio central siempre tiene éxito. El sistema puede proporcionar funciones para fusionar cambios adicionales en el repositorio central y preservar los cambios del primer desarrollador cuando otros desarrolladores se registran.
Fusionar dos archivos puede ser una operación muy delicada y, por lo general, solo es posible si la estructura de datos es simple, como en los archivos de texto . Es posible que el resultado de una combinación de dos archivos de imagen no dé como resultado un archivo de imagen. El segundo desarrollador que verifique el código deberá tener cuidado con la combinación, para asegurarse de que los cambios sean compatibles y que la operación de combinación no introduzca sus propios errores lógicos dentro de los archivos. Estos problemas limitan la disponibilidad de operaciones de combinación automáticas o semiautomáticas principalmente a documentos simples basados en texto, a menos que esté disponible un complemento de combinación específico para los tipos de archivos.
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 revisiones utilizarán solo uno de estos términos similares (línea base, etiqueta, etiqueta) para referirse a la acción de identificar una instantánea ("etiquetar el proyecto") o el registro de la instantánea ("pruébelo con la línea base X "). . Normalmente sólo uno de los términos línea base , etiqueta o rótulo se utiliza 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 importantes que otras, como las que se utilizan para indicar lanzamientos, ramas o hitos publicados.
Cuando tanto el término línea de base como el de etiqueta o rótulo se usan juntos en el mismo contexto, etiqueta y etiqueta generalmente se refieren al mecanismo dentro de la herramienta para identificar o realizar el registro de la instantánea, y línea de base indica la mayor importancia de cualquier etiqueta determinada. o etiqueta.
La discusión más formal sobre la gestión de la configuración utiliza el término línea base .
Los sistemas de control de revisiones distribuidos (DRCS) adoptan un enfoque de igual a igual, a diferencia del enfoque cliente-servidor de los sistemas centralizados. En lugar de un repositorio único y central en el que los clientes se sincronizan, la copia de trabajo del código base de cada par 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 como resultado algunas diferencias importantes con respecto a un sistema centralizado:
Más bien, la comunicación sólo es necesaria cuando se impulsan o impulsan cambios hacia o desde otros pares.
Es necesario seguir las mejores prácticas para obtener todos los beneficios del control de versiones. Las mejores prácticas 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 involucran solo una tarea o solución; un corolario de esto es confirmar solo código que funcione y que no rompa 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 utilizando 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 variarán 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 obtener la licencia del software de control de versiones, utilizar el control de versiones requiere tiempo y esfuerzo. Se deben comprender los conceptos subyacentes al control de versiones y se deben aprender los detalles técnicos necesarios para operar el software de control de versiones elegido. Las mejores prácticas de control de versiones deben aprenderse e integrarse en las prácticas de desarrollo de software existentes de la organización. Es posible que se requiera un esfuerzo de gestión para mantener la disciplina necesaria para seguir las mejores prácticas a fin de obtener beneficios útiles.
Un beneficio principal es la capacidad de mantener el 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 ayuda con la implementación. La ramificación y fusión, la producción, empaquetado y 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 diversas etapas del proceso de implementación; desarrollo, pruebas, puesta en escena, producción, etc. [15]
Puede haber mitigación de daños, responsabilidad, 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] Esto puede permitir una mejor reevaluación de por qué se realizaron cambios para abordar los problemas y las soluciones en el futuro. [17]
Cuando surgen errores, saber qué se hizo y cuándo ayuda a mitigar y recuperar los daños al ayudar a identificar qué problemas existen, cuánto tiempo han existido y determinar el alcance y las soluciones del problema. [18] Se pueden instalar y probar versiones anteriores para verificar las conclusiones alcanzadas mediante el examen del código y los mensajes de confirmación. [19]
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. [20] El desarrollador no necesita estar familiarizado con todo el código base 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 los desarrolladores. [21]
El empaquetado de confirmaciones, ramas y todos los mensajes de confirmación y etiquetas de versión asociados mejora la comunicación entre los desarrolladores, tanto en el momento como a lo largo del tiempo. [22] Una mejor comunicación, ya sea instantánea o diferida, puede mejorar el proceso de revisión del 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 funciones, lo que permite una integración más profunda con otras herramientas y procesos de ingeniería de software.
Los complementos suelen estar 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. [23]
La terminología puede variar de un sistema a otro, pero algunos términos de uso común incluyen: [24]
Una revisión aprobada de un documento o archivo fuente al que se pueden realizar cambios posteriores. Ver líneas base, etiquetas y rótulos.
Una búsqueda del autor y 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 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 un 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 identifica 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 como cualquier ID de lista de cambios en particular.
Revisar (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 "pago" también se puede utilizar como sustantivo para describir la copia de trabajo. Cuando un archivo se ha extraído de un servidor de archivos compartido, otros usuarios no pueden editarlo. Piense en ello como un hotel: cuando realiza el check out, ya no tiene acceso a sus comodidades.
Clonar significa crear un repositorio que contiene las revisiones de otro repositorio. Esto equivale a empujar o tirar a 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 , submit o record ) es escribir o fusionar los cambios realizados en la copia de trabajo en el repositorio . Una confirmación contiene metadatos, normalmente la información del autor y un mensaje de confirmación que describe el cambio.
Una breve nota, escrita por el desarrollador, almacenada con la confirmación, que describe la confirmación. Idealmente, registra 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 diferentes partes realizan cambios en el mismo documento y el sistema no puede conciliar los cambios. Un usuario debe resolver el conflicto combinando los cambios o seleccionando un cambio a favor del otro.
La mayoría del software de control de revisiones utiliza compresión delta , que conserva sólo las diferencias entre versiones sucesivas de archivos. Esto permite un almacenamiento más eficiente de muchas versiones diferentes de archivos.
Una secuencia en la que algunas o todas las versiones de archivos son espejos de las versiones de la secuencia principal.
Exportar es el acto de obtener los archivos del repositorio. Es similar a realizar check-out 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 los contenidos, por ejemplo.
Ver tirar .
El proceso de fusionar los cambios realizados en el tronco principal en una rama de desarrollo (característica o equipo).
A veces también llamado consejo , se refiere a la confirmación más reciente, ya sea en la troncal o en una rama. El tronco y cada rama tienen su propia cabeza, aunque a veces se usa HEAD de manera vaga para referirse al tronco. [30]
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 revisiones utilizan deltas intercalados , un método que permite almacenar el historial de archivos basados en texto de una forma más eficiente que utilizando la compresión Delta .
Ver etiqueta .
Cuando un desarrollador bloquea un archivo, nadie más puede actualizarlo hasta que se desbloquee. El bloqueo puede ser respaldado por 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 escenarios de muestra 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 una secuencia a su padre. [32]
Copie revisiones de un repositorio a otro. La extracción la inicia el repositorio receptor, mientras que la inserción la inicia el origen. Fetch se utiliza a veces como sinónimo de extracción , 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 comúnmente mediante una solicitud de extracción, también conocida como solicitud de fusión. [33] El colaborador solicita que el mantenedor del proyecto realice el cambio en el código fuente, de ahí el nombre "solicitud de extracción". El mantenedor tiene que fusionar la solicitud de extracción si la contribución debe pasar a formar parte de la base fuente. [34]
El desarrollador crea una solicitud de extracción para notificar a los mantenedores sobre un nuevo cambio; un hilo de comentarios está asociado con cada solicitud de extracción. Esto permite una discusión centrada en los cambios de código . Las solicitudes de extracción enviadas son visibles para cualquier persona con acceso al repositorio. Los mantenedores pueden aceptar o rechazar una solicitud de extracción. [35]
Una vez que la solicitud de extracción se revisa y aprueba, se fusiona en el repositorio. Dependiendo del flujo de trabajo establecido, es posible que sea necesario probar el código antes de incluirlo en el lanzamiento oficial. Por lo tanto, algunos proyectos contienen una rama especial para fusionar solicitudes de extracción no probadas. [34] [36] Otros proyectos ejecutan un conjunto de pruebas automatizadas en cada solicitud de extracción, utilizando una herramienta de integración continua , y el revisor verifica que cualquier código nuevo tenga una cobertura de prueba adecuada.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 dado de todo el árbol en el repositorio.
El acto de hacer que un archivo o carpeta esté disponible en varias ramas al mismo tiempo. Cuando un archivo compartido se modifica en una rama, se cambia en otras ramas.
Un contenedor para archivos ramificados que tiene una relación conocida con otros contenedores similares. Los arroyos forman una jerarquía; cada secuencia puede heredar varias propiedades (como versiones, espacio de nombres, reglas de flujo de trabajo, suscriptores, etc.) de su secuencia principal.
Una etiqueta o etiqueta hace referencia a una instantánea importante en el tiempo, coherente en muchos archivos. En ese momento, todos estos archivos pueden etiquetarse con un nombre o número de revisión significativo y fácil de usar. Ver 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 Baseline, Mainline o Master [39] [40] )
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 es también el término utilizado por algunas herramientas CM (CM+, PLS, SMS) para el concepto de paquete de cambios (ver lista de cambios ). Sinónimo de pago en sistemas de control de revisiones 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 archivos de un repositorio, en un momento o revisión específica. Todo el trabajo realizado con los archivos de un repositorio se realiza inicialmente en una copia de trabajo, de ahí el nombre. Conceptualmente, es un sandbox .
En términos de horas de trabajo, le costará entre 6 y 48 veces lo que le habría costado usar el control de versiones, y eso es por rebobinar un par de modelos para un solo desarrollador.
Los sistemas de control de versiones le permiten comparar archivos, identificar diferencias y fusionar los cambios si es necesario antes de enviar 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 está actualmente en desarrollo, control de calidad y producción.
La historia del documento proporciona información invaluable sobre el autor y la fecha de edición.
También da 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 los problemas experimentados en versiones anteriores.
La capacidad de identificar al autor del documento permite al equipo actual vincular los documentos a contribuyentes 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.
Además, si con el tiempo, la adición de una determinada característica causa dificultades para extender o expandir el proyecto, el uso del control de versiones permite a los desarrolladores rastrear esa característica en particular y cambiarla o eliminarla sin afectar la funcionalidad del proyecto.
Los equipos de software pueden comprender la evolución de una solución examinando versiones anteriores mediante revisiones de código.
Si se comete un error, los desarrolladores pueden retroceder en el tiempo y revisar iteraciones anteriores del código para remediar el error y minimizar las molestias para todos los miembros del equipo.
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 mediante una búsqueda binaria automática.
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 eventualmente se pisarán unos a otros y sobrescribirán los cambios de código que otra persona pudo haber completado sin siquiera darse cuenta.
El uso de estos sistemas le permite comprobar si hay modificaciones en los archivos y luego, durante el registro, si otro usuario ha modificado 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: comunicar.