Lo que muchos no saben sobre los sistemas de control de versiones.

POST

Más sobre el tema.

Osvaldo Galván

Osvaldo Galván

Los sistemas de control de versiones ayuda a registrar los cambios en un archivo o grupo de archivos. Por lo tanto, podamos recuperar una versión especifica de un archivo en momento determinado.

Los sistemas de control de versiones generalmente se usan para controlar los cambios del código fuente de una aplicación. No obstante, puedes usarlos para administrar cualquier tipo de documento.

Estos trabajan al nivel del sistema de archivo. En consecuencia, monitorean cambios, adiciones y eliminación de archivos y/o carpetas.

Un sistema de control de versiones funciona mejor con archivo de texto plano. Ya que, permite identificar la adición, eliminación y modificación de las líneas del archivo.

Adicionalmente, puedes mezclar dos versiones del mismo archivo en uno solo.

En caso de querer versionar archivos binarios, como son las imágenes. Es posible hacerlo. Sin embargo, al intentar unir dos archivos binarios, pudieses obtener resultados poco deseados.

La importancia de contar con un sistema de control de versiones.

Contar o no con un sistema de control de versiones es una decisión propia. Sin embargo, no tenerlo podría significar tiempo y el dinero perdido.

Un sistema de control de versiones permite entre otras cosas:

  • Guarda el registro histórico de las modificaciones realizadas a cada archivo y/o carpeta.
  • Añade trazabilidad al desarrollo de software. Por lo tanto, permite identificar cambios entre una versión y otra.
  • Colaboración de varios desarrolladores en el mismo proyecto.
  • Ayudan a gestionar y unir los diferentes archivos del proyecto.
  • Evita que pierdas información que por error se haya modifica o borrado accidentalmente.
  • Es posible revertir o deshacer los cambios realizados en el archivo.

Como ingeniero de software es importante considerar un sistema de control de versiones para gestionar los cambios al código fuente.

No es suficiente respaldar el código de tu aplicación en otra carpeta de tu computadora. Por el contrario, de esta forma podrás perder capacidad de comparar versiones diferentes de código.

Arquitecturas.

Los sistemas de control de versiones han evolucionado como los programadores lo han requerido. Desde las copias locales, hasta complejos sistemas que permiten la colaboración de varios programadores en un mismo proyecto.

Por lo tanto, según su arquitectura los sistemas de control de versiones se dividen en: Locales, centralizados y distribuidos.

Locales.

Consiste en crear copias locales de tus archivos en otra carpeta de tu computadora.

Este sistema se caracteriza por ser fácil de implementar. Es decir, copias, pegas y renombras directorios.

Su principal desventaja radica en la poca o nula trazabilidad que se puede dar a cada archivo.

Si accidentalmente borraras una carpeta que contenía X versión de tu código, no será posible recuperar esa información.

La combinación de archivos puede ser casi imposible. Aunque puedes hacer uso de ciertas herramientas (enlace herramientas) para combinar archivos, perderás el registro de tus cambios.

Al ser un sistema local, es imposible que alguien más colabore en tus proyectos. Al menos que quieras prestarle tu computadora a alguien más.

Sistema local de control de versiones.
Sistema local de control de versiones.

Centralizados.

Al principio, teníamos solo copias locales, ahora, pasamos a las copias en un servidor dedicado.

Es decir, un sistema centralizado es un sistema cliente – servidor.

Lo sistemas centralizados se caracterizan por almacenar una copia del código fuente en una base de datos central.

Por consiguiente, cualquier usuario que tenga acceso a la base de datos, también puede hacer una copia y modificar los archivos.

Cuando el usuario termina de modificar el archivo, solicita al control de versiones que aplique los cambios en la versión del servidor.

Pero no todo es hermoso. Si dos programadores trabajan en el mismo archivo. Solo el primero que envíe sus cambios podrá hacerlo de forma limpia.

El segundo tendrá que fusionar los archivos de forma manual. Solo hasta que están integrados los cambios el resto de los programadores podrán continuar trabajando.

Por otra parte, si el servidor central falla, nadie podrá colaborar en el proyecto.

Sistema local de control de versiones.
Sistema central de control de versiones

Distribuidos.

A diferencias de los sistemas centralizados, un sistema distribuidos, tiene una copia central, pero cada programador puede replica una copia local del código fuente.

Por lo tanto, cada programador puede trabajar de forma aislada. Asimismo, este sistema cuenta con herramientas que facilitan la resolución de conflictos.

Sobre todo, al ser un sistema distribuido, no requieres estar conectado al servidor central para poder trabajar.

Aunque permiten la colaboración de múltiples programadores. Solo el administrador de repositorio puede aceptar o rechazar cambios.

Por supuesto, al permitirse múltiples copias de código fuente, se puede perder el control de quién tiene copias de este.

Sistema distribuido de control de versiones.
Sistema distribuido de control de versiones.

Sistemas de control que puedes elegir.

Ahora, es momento de elegir qué sistema de control de versiones usar. Primero, podemos considerar las siguientes opciones: Baazar, Subversion, Mercurial y Git.

Yo en particular trabajé con Mercurial, actualmente trabajo con GIT en Azure DevOps.

Baazar

ArquitecturaDistribuida
Fecha de lanzamiento26 de marzo de 2005
Programado enPyton
Desarrollado porCanonical Proyecto GNU
AutorMartin Pool
Sitio OficialBaazar Oficial Site

Apache Subversion

ArquitecturaCliente – Servidor
Fecha de lanzamiento20 de octubre de 2000
Programado enC
Desarrollado porApache Software Foundation
AutorCollabNet, Inc.
Sitio OficialApache Subversion Oficial Site

Mercurial

ArquitecturaDistribuida
Fecha de lanzamiento19 de abril de 2005
Programado enMayormente en Python con pequeñas partes portables en C.
AutorMatt Mackall
Sitio OficialMercurial Oficial Site

GIT

ArquitecturaDistribuida
Fecha de lanzamiento7 de abril de 2005
Programado enC, Bourne Shell, Perl
Desarrollado porLinus Torvalds, Junio Hamano, Software Freedom Conservancy
AutorLinus Torvalds
Sitio OficialGIT Oficial Site

Aunque los ejemplos antes mencionados, guardan similitudes en cuanto arquitecturas.

Definitivamente, tienes que elegir un sistema de control de versiones para tus proyectos.

Preguntate, si eres el único programador o estarás colaborando con otros. Si prefieres tener todo el código en un repositorio central o que esté distribuido.

La respuesta a estas preguntas, sin duda, puede ayudarte a tomar una decisión.

Yo por ejemplo, primero, comence trabajando con Tortoise H. Use Mercurial. Pero cancelamos la suscripción porque el costo era excesivo.

Después, comence a usar Microsoft Azure DevOps, actualmente trabajo en un proyecto en .NET. Por tanto, uso repositorios GIT desde DevAzure

Con Microsoft Azure DevOps ahorramos costos de desarrollo, porque, hacemos uso de los repositorios gratuitos que este ofrece.

En conclusión, son múltiples los factores pueden afectar tu toma de decisión. Pero por favor, nunca dejes de usar sistema de control de versiones.

Terminología Básica.

Anteriormente hablamos de arquitectura y tipos de sistemas de control de versiones.

Aunque estos sistemas sean diferentes, guardan ciertas similitudes en cuanto a los términos que usa.

Repository

Es el lugar principal donde se almacena el código. Por tanto, es aquí donde se puede consultar fácilmente los cambios realizados a cada archivo.

Version

A cada versión corresponde un conjunto de cambios realizados por un programador. Las revisiones son reconocidas por un identificar único asignado por el sistema de control de versiones.

Tag

Con el objeto de reconocer cada versión del repositorio, el sistema de control de versiones asigna un identificado único a cada una. Sin embargo, para un desarrollador, no es fácil recordar dicho número.

Por lo tanto, en caso de que querer asignar un identificador amigable, podemos hacer unos de etiquetas.

En otras palabras, las etiquetas son fáciles de recordar y localizar entre las versiones del repositorio.

Branch

Un repositorio puede tener una o más rama. Cada rama representa una copia exacta de un momento específico del repositorio.

Las ramas usualmente se usan para que cada desarrollador trabaje aisladamente del resto.

Se recomienda tener al menos uno rama principal (master), otra de desarrollo (develop) y una adicional por cada programador en el proyecto.

Checkout

Solicitud explicita de hacer una copia o cambio de rama en el equipo local del programdor.

Se puede hacer un checkout en cualquier versión de la rama principal o subramas.

Change

Modificación de uno o varios archivos de una rama. Los cambios se envían a la rama principal después de ejecutar un commit.

Commit

Instrucción que Indica el envío de cambios a la rama principal del repositorio. Primero, deberán pasar por un proceso de resolución de conflictos. Esto solo si es necesario.

Conflicto.

Sucede cuando dos o más programadores enviaron cambios del mismo archivo a una rama en el repositorio.

Por tanto, el sistema de control de versiones, en la mayoría de las circunstancias, es capaz de resolver los conflictos entre archivos.

Resolve.

En el caso de, si el sistema de control de versiones no puedo resolver los conflictos automáticamente. Solicitará a la ultima persona que envió sus cambios, resolver manualmente los conflictos entre archivos.

Merge.

Unión de dos ramas o conjunto de cambios. Siempre que, un desarrollador envia sus cambios a la rama principal, este deberá realizar un merge para combinar sus cambios con la rama principal.

Changelist.

Se define como la lista de cambios incluidas en un commit o versión específica del repositorio. Por cada changelist, se puede ver de forma fácil los archivos afectados en el commit.

Sync.

Comando que integra los cambio del repositorio remoto al repositorio local.

En conclusión, estos son solo algunos términos que podemos encontrar en los sistemas de control de versiones. Cada sistema tiene sus propios nombres. Pero guardan similitud con esta especificación.

Facebook
Twitter
LinkedIn
Osvaldo Galván

Osvaldo Galván

Osvaldo Galván Software Engennier Enfocado en la calidad del software,

Deja un comentario

Tu dirección de correo electrónico no será publicada.