¿GIT o SVN? Mantén el último cambio

¿A cuántas personas no le sucede que, luego de mucho trabajo, pierden todos los avances por un fallo del sistema u otro motivo? Frustrante, ¿verdad?

La realidad es que suele suceder con mucha frecuencia, aun cuando las tecnologías en la nube han disminuido estos hechos en gran medida.

Sin embargo, en el desarrollo de productos informáticos, no solo perder lo trabajado es problema, también lo es mantener un control estricto de los cambios, modificaciones o mejoras que se realizan.

Y es en este punto donde surge el llamado control de versiones.

Antes de entrar en materia, y como es costumbre ya, traigo algunos términos generales.

Qué es el control de versiones

El término de control de versiones se le atribuye a los cambios que se realizan, en especial sobre elementos particulares de un producto o a su configuración.

Los elementos pueden ser, por ejemplo:

• Código fuente
• Partes del diseño
• Componentes de software

Aunque es posible mantener el control de versiones si somos lo suficientemente organizados, es cierto que el apoyo de una herramienta automatizada que facilite el trabajo es mucho mejor.

Con este propósito existen los sistemas de control de versiones, que además tienen ciertas ventajas:

• Funcionan como un punto de almacenamiento de la información
• Permiten modificar los elementos almacenados, sin perder el anterior
• Favorecen la trazabilidad de los cambios, generando el históricos de las acciones que se realizan
• Posibilitan recuperar el producto desde un punto específico, si es necesario.

Basado en esta tecnología son varias las herramientas que existen con el mismo objetivo base, pero diferentes características.

Hoy le presento dos de estas herramientas, que son las más populares, para que decidas cuál deseas utilizar: GIT o SVN.

GIT

Diseñado por Linux Torvald, GIT pasó de ser un motor de bajo nivel a un sistema de control de versiones con un grupo de funcionalidades muy codiciadas en el mundo del desarrollo de software.

Es principalmente utilizado para sistemas que poseen gran cantidad de archivos de código fuente, que siguen un desarrollo no lineal y que por tanto la relación entre los cambios no es necesariamente igual para todos los archivos.

De manera simplificada esto se traduce en que el control de versiones que propone GIT funciona de la siguiente manera:

• Se crean ramas de diferentes niveles, para diferentes miembros del equipo de desarrollo, incluidos desde planificadores hasta probadores (tester).
• Estas ramas, conocidas como ramas locales, son hijas de una rama master, que solo se actualiza para construir todos los cambios de una versión final del producto.
• Cada desarrollador puede trabajar local con su rama, probarla e integrarla, desde su propio GIT, sin afectar el funcionamiento del resto.
• Una vez que los cambios locales están probados, se entregan paulatinamente las ramas, antes de sincronizar en la rama master.

Mostrándolo visualmente quedaría algo así:

Otras características que favorecen su popularidad son:

• La integración con otras herramientas como los entornos de desarrollo (IDEs).
• El soporte de varios protocolos como HTTP, FTP o SSH.
• Funcionamiento como repositorio de sistemas y sus versiones.
• Compatibilidad con GITHub.

Este último aspecto posee una gran relevancia pues permite llevar un control de versiones seguro en grupos de trabajo más pequeños, que después pueden integrase en la nube mediante GITHub, y lograr mayor disponibilidad y distribución de versiones estables de un software o producto.

Algunos términos técnicos:

• Master: es la rama principal y se publica en entornos de producción. Solo debe sincronizarse si se garantiza su estabilidad.
• Development: Es una rama sacada directamente de la Master. Contiene lo mismo, pero se utiliza como rama de integración. Sobre esta se realizan las actualizaciones en desarrollo, se integran y se corrigen los errores antes de publicar en la rama Master.
• Features: Son las ramas especificas o locales que heredan de la rama Development.  Se crean cuando surgen nuevas funcionalidades, que una vez concluidas se integran con el resto, en la rama Development.
• Release: Son ramas que se crean para generar las nuevas versiones de un producto ya en producción. En esta rama se corrigen los errores menores y se preparan los metadatos, teniendo como raíz la rama Development.

Las acciones de actualización de ficheros se realizan con palabras claves que GIT entiende, y que se ejecutan según parámetros específicos:

• Init: crea un proyecto nuevo de git, con la estructura básica a partir de la cual se comienza a generar un nuevo proyecto.
• Push: sube la rama que se especifica a un servidor remoto configurado.
• Merge: actualiza los cambios de la rama en la que se está trabajando.
• Commit: confirma la actualización de los cambios realizados.

También te puede interesar leer: API testing, las mejores tecnologías

SVN

Subversion, nombre al que responden las siglas SVN, es un sistema de control de versiones que está indicado para funcionar como un sistema de ficheros similar al que poseen los sistemas operativos comunes.

Su papel principal es el de posibilitar el trabajo como repositorio, para almacenar cambios en los datos almacenados.

SVN parte del concepto de revisión, como una técnica para comparar cambios realizados anteriormente y almacenar el conjunto de modificaciones realizadas entre un cambio y otro.

De esta forma mantiene optimizado los recursos de almacenamiento donde se despliega el repositorio.

El acceso dentro del sistema de ficheros del repositorio SVN varía según permisos que se asignan a los usuarios y limitan las acciones que estos pueden realizar.

Sin embargo, varios de ellos pueden modificar e incluso eliminar información común. Debido a esto y la flexibilidad para trabajar en cambios desde svn, es necesario que las personas que lo utilicen conozcan y apliquen buenas prácticas de control de versiones.

En este caso, también es posible el acceso remoto a la información utilizando las redes, y es posible genera ramas, similar a como lo hace GIT.

De esta forma se crean entornos diferentes que serán trabajados de manera aislada hasta que se encuentren en condiciones de ser integrados.

Los cambios generados en un conjunto pueden ser aplicado a otro utilizando el comando merge, pero siempre desde la perspectiva de aplicar los cambios detectado en una revisión.

O sea, la comparación entre dos cambios, donde SVN solo trabaja con el conjunto de modificaciones resultantes.

En este tipo de herramienta se utiliza una estructura central que reponde a las siglas TTB, resultado del nombre de las tres carpetas principales que la componen:

• Trunk: Rama principal.
• Tags: Rama donde se aplica la gestión de las versiones. Esta rama no permite que se desarrolle sobre ella.
• Branches: Ramas paralelas, que evolucionan a ramas Trunk.

Una idea de cómo manejar el control de versiones con SVN sería:

• Se crea un proyecto de desarrollo sobre el cual se trabajará hasta conseguir una versión cerrada, que significa estable.
• Esta versión se pone en producción, y se inicia entonces el trabajo sobre una nueva versión.
• Cada versión responde a un conjunto de acciones, que inciden en diferentes partes del proyecto: Actualización de la rama Truck mediante trabajo en equipos, u otro tipo de modificación combinando practicas con partes de la estructura del proyecto.

También te puede interesar leer: Heroku: despliega tu aplicación en la nube en 3 minutos

GIT vs SVN

La elección de qué herramienta utilizar depende siempre del objetivo del usuario. Entrando en una comparativa, y tratando temas esenciales, se pueden valorar algunas cualidades.

• Enfoque:

Los objetivos esenciales de ambos es lograr el control de los cambios que se realizan sobre un proyecto. Y ambos posibilitan trabajar en diferentes proyectos.

Sin embargo, debido a la naturaleza de las acciones que permite GIT es aconsejable utilizarlo para proyectos más grandes, y con un equipo igualmente mayor.  

SVN en ese caso, puede seleccionarse en caso de que las personas que acceden al proyecto sean 2 o 3 de ellas, y el número de ficheros que se manejan sea menor.

• Estructura:

SVN está totalmente estructurado en carpetas, generando almacenamientos una dentro de otra, según las necesidades del proyecto; dígase un tipo de arquitectura, la organización que propone una metodología, entre otros.

• Accesibilidad:

La diferencia en este aspecto es clara. SVN es un sistema centralizado, o sea, el sistema de ficheros creado para un proyecto se encuentra en un único punto al cual se accede desde la red, para realizar los cambios, las revisiones o aquellas acciones que sean necesarias.

GIT por es distribuida. Significa que existe un proyecto general, y los diferentes miembros del equipo pueden tener un proyecto en desarrollo de manera local. De esta forma pueden trabajar en sus ramas, sin necesidad de conectarse al proyecto principal.

• Trazabilidad:

La trazabilidad se refiere al seguimiento que se puede tener de los cambios que se realizan. En este aspecto se debe tener en cuenta que SVN solo permite comparar las modificaciones entre dos cambios, y de ello extrae el conjunto que se debe almacenar.

De esta forma no es posible regresar a cualquier punto, sino que debe ser necesariamente al anterior.

En el caso de GIT es posible que cada miembro del equipo cree nuevos proyectos, donde realiza copias de los cambios integrados en su rama o en la rama master, y continuar en el proyecto principal.

La cantidad de cambios a registrar es ilimitada, por lo que siempre se puede regresar al punto donde deseemos, sin importar la cantidad de cambios realizados anteriormente.

Espero que la comparación le sea útil para seleccionar la herramienta que más se acerque a sus necesidades.