Control de versiones: por qué no puedes vivir sin él

Si usa una computadora, probablemente se haya enfrentado al problema de las diferentes versiones de archivos. Ya sea que se trate de archivos de texto, archivos de datos o código de programa que ha estado escribiendo, siempre se enfrentará a la decisión de guardar y reemplazar la versión anterior o guardar además de la versión anterior.


Para los desarrolladores individuales, ya es un desafío realizar un seguimiento de las diferentes versiones de un programa, sin mencionar todas las diferentes copias de seguridad que puede hacer.

Ahora imagine que está trabajando como parte de un equipo en un proyecto que incluye texto, multimedia y codificación; en resumen, una gran variedad de información en proceso..

Imagínese más: digamos que cada archivo de datos o programa es trabajado por varias personas (“concurrencia”), cada persona agrega, guarda, edita y guarda de nuevo. ¿Cómo sabrá quién hizo qué, cuándo y por qué, y podrá rastrear todos estos cambios??

Necesita control de versiones (VC).

En este artículo, veremos qué es el control de versiones y cómo ha evolucionado a lo largo de los años hasta la última generación..

En particular, veremos Git, la aplicación de control de versiones cada vez más popular de las personas que hicieron Linux, y veremos algunos ejemplos de cómo usaría Git para recuperar el control de todas esas diferentes revisiones de sus archivos.

Una cartilla para la jerga VC

El control de versiones tiene su propio lenguaje. Después de especificar qué directorios o grupos de archivos deben rastrearse sus cambios, los directorios o archivos se conocen como repositorio o repositorio..

Los cambios se rastrean automáticamente, pero solo se registran como una sola colección de acciones, llamada confirmación, y se registran como un conjunto de cambios con un número de revisión único. Esto asegura que pueda llamar la última versión de un archivo.

Si desea comparar dos revisiones (por ejemplo, si un error se deslizó en su código en algún momento), la herramienta de control de versiones debería permitirle diferenciar dos archivos, lo que significa ver las diferencias entre los dos.

Para experimentar con un repositorio sin arriesgar problemas o daños, puede crear una rama, es decir, una copia del repositorio, que luego puede modificar en paralelo. Si los cambios en la rama son satisfactorios, puede fusionar la rama con el repositorio principal (maestro) o incluso otra rama.

Al fusionar, los sistemas de control de versiones modernos suelen ser lo suficientemente inteligentes como para determinar qué cambios deben incluirse desde qué rama o repositorio, de acuerdo con el historial de cambios mantenido para cada uno. Si un sistema de control de versiones no puede decidir, entonces es posible que deba resolver manualmente un conflicto.

Evolución de sistemas de control de versiones

Las herramientas de control de versiones han aparecido en tres generaciones hasta ahora, cada generación agrega flexibilidad y posibilidades de concurrencia..

Primera generación

Con los sistemas de control de versiones originales, aunque varias personas podían trabajar en el mismo archivo, no podían hacerlo simultáneamente. El archivo fue bloqueado para evitar que otros accedan al mismo tiempo.

Un ejemplo de dicha herramienta es SCCS (Sistema de control de código fuente) para el desarrollo de software desde 1972 en adelante. RCS (Revision Control System) se creó como la alternativa gratuita a SCCS y ofreció una operación, ramificaciones y fusión más rápidas (todavía solo permite que un desarrollador trabaje en un archivo en un momento dado).

Segunda generación

Muchos controles de versión en funcionamiento hoy están en esta categoría. Son posibles modificaciones simultáneas en los archivos, aunque los usuarios deben fusionar las revisiones actuales en su trabajo antes de que puedan comprometerse.

CVS (Sistema de versiones concurrentes) es una instancia y permite interacciones cliente / servidor con el uso de un repositorio. SVN (o Apache Subversion en su totalidad) es posiblemente el más popular de todos los sistemas de control de versiones en uso hoy en día..

SVN puede considerarse como un rediseño de CVN con una base moderna y soluciones a las limitaciones anteriores de CVS.

Tercera generación

También conocido como DVCS (Sistemas de control de versiones distribuidas), con la posibilidad de separar las operaciones de fusión y confirmación, uno de los ejemplos más conocidos es Git.

Ya no hay una base centralizada para archivos; diferentes ramas tienen diferentes partes, lo que también abre la puerta a trabajar en revisiones fuera de línea.

Un ejemplo real usando Git

¿Cómo se ven las operaciones descritas anteriormente cuando se utiliza un sistema de control de versiones de la vida real??

Tomamos Git como ejemplo aquí, usando la línea de comando de Linux. Primero, creamos un repositorio Git para el directorio en el que estamos actualmente. Usamos el comando pwd para ver dónde estamos:

1
2

$ pwd

/ Users / HJ / Desktop / repos / apps

Luego usamos el comando git init para crear el repositorio (el repositorio “maestro”) y obtener la confirmación de Git:

1
2

$ git init

Inicializado repositorio Git vacío en /Users/HJ/Desktop/repos/apps/.git

Supongamos que agregamos un nuevo archivo, main.c, a nuestro directorio de trabajo. El uso del comando git status nos dará la siguiente información:

1
2
3
4 4
5 5
6 6
7 7
8
9 9

$ git status

# En el maestro de sucursal
# #
# Compromiso inicial
# #
# Archivos sin seguimiento:
# (utilizar "git add …" para incluir en lo que se comprometerá)
# #
# C Principal

Usamos git add para rastrear el archivo main.c

1 $ git add main.c

Usamos git commit con un mensaje (opción -m) sobre lo que estamos haciendo para confirmar los cambios en el archivo main.c.

1 $ git commit -m "agregando main.c al repositorio"

Ahora podemos crear una rama (por ejemplo, “prueba”) con el comando git branch:

1 prueba de $ git branch

Usar el comando git branch nuevamente solo enumera los repositorios que ahora tenemos:

1
2
3

$ git branch

prueba

* Maestro

Finalmente, para comenzar a trabajar en la rama “prueba” en la copia de main.c ahora en esa rama, usamos el comando git checkout para obtener la confirmación de que ahora estamos trabajando en la rama “prueba”.

1
2

prueba de pago de $ git

Cambiado a rama "prueba"

Para volver a la rama “maestra”, simplemente use el comando git checkout nuevamente:

1
2

$ git checkout master

Cambiado a rama "Maestro"

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Adblock
    detector