En el software de control de versiones , un conjunto de cambios (también conocido como commit [1] y revisión [2] [3] ) 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 . [4] [5]
En el sistema de control de versiones de Git , un conjunto de cambios se denomina confirmación, [1] que no debe confundirse con la operación de confirmación que se utiliza para confirmar un conjunto de cambios (o en el caso de Git, técnicamente una instantánea [1] ) en un repositorio. [6]
Otros sistemas de control de versiones también utilizan otros nombres para referirse a los conjuntos de cambios, por ejemplo, Darcs los llama "parches", [7] mientras que Pijul se refiere a ellos como "cambios". [8]
Los sistemas de control de versiones adjuntan metadatos a los conjuntos de cambios. Los metadatos típicos incluyen una descripción proporcionada por el programador (un "mensaje de confirmación" en la jerga de Git), el nombre del autor, la fecha de la confirmación, etc. [9]
Los identificadores únicos son una parte importante de los metadatos que los sistemas de control de versiones adjuntan a los conjuntos de cambios. Los sistemas de control de versiones centralizados, como Subversion y CVS, simplemente utilizan números crecientes como identificadores. [10] [11] Los sistemas de control de versiones distribuidos , como Git , generan un identificador único aplicando una función hash criptográfica al conjunto de cambios. [12]
Dado que los sistemas de control de versiones operan con conjuntos de cambios como unidades atómicas y que la comunicación dentro de los equipos de desarrollo mejora el rendimiento, existen ciertas prácticas recomendadas que se deben seguir al crear conjuntos de cambios. Aquí solo se mencionan las dos más importantes: la atomicidad del contenido de los conjuntos de cambios y las descripciones de los conjuntos de cambios.
El contenido del conjunto de cambios debe implicar solo una tarea o solución y contener solo código que funcione y que no rompa deliberadamente la funcionalidad existente. [13]
Las descripciones de los conjuntos de cambios deben ser breves, registrando por qué se realizó la modificación, el efecto o propósito de la modificación y describiendo aspectos no obvios de cómo funciona el cambio. [14]
Escribe la menor cantidad de código posible para resolver un problema. Después de identificar un problema o una mejora, la mejor manera de probar algo nuevo y no probado es dividir la actualización en pequeños lotes de valor que se puedan probar fácil y rápidamente con el usuario final para demostrar la validez de la solución propuesta y revertir en caso de que no funcione sin desaprobar toda la nueva funcionalidad. ... En relación con la realización de pequeños cambios, las confirmaciones atómicas son una sola unidad de trabajo, que implica solo una tarea o una corrección (por ejemplo, actualización, corrección de errores, refactorización). Las confirmaciones atómicas hacen que las revisiones de código sean más rápidas y las reversiones más fáciles, ya que se pueden aplicar o revertir sin efectos secundarios no deseados. El objetivo de las confirmaciones atómicas no es crear cientos de confirmaciones, sino agrupar las confirmaciones por contexto. Por ejemplo, si un desarrollador necesita refactorizar código y agregar una nueva característica, crearía dos confirmaciones separadas en lugar de crear una confirmación monolítica que incluya cambios con diferentes propósitos.
El seguimiento de cambios... proporciona un análisis de los cambios anteriores, así como una visión holística de la trayectoria del conjunto de datos. El historial del documento... proporciona información sobre
el
propósito de los cambios realizados.