Sistemas para Control de Versiones de Software

Hola amigos, bienvenidos a un nuevo post de nuestro blog donde tenemos como  invitado a un muy amigo mio  Osvaldo Alcantara Terrazas  él es Licenciado en Informática Administrativa, tiene una Maestría en Dirección de Sistemas de Información y  más de 10 años de experiencia laborar en el área de Desarrollo y Soluciones de Software. 

Él  es nuestro primer invitado y nos va a platicar de la importancia de tener ordenado nuestro software, porque muchas ocasiones de no hacerlo se nos puede volver un dolor de cabeza. También nos presenta una herramienta de control de versiones la cual por cierto les adelanto es gratuita y siguiendo la temática de este blog nos comparte ejemplos muy completos, seguro los va a convencer de utilizarlo. 

Espero les agrade este post, nos compartan, dejen sus dudas, comentarios, opiniones, retroalimentaciones, sugerencias. 

Leamos a Osvaldo:

Todos en algún momento de hemos tenido que modificar programas, ya sea por mejoras o por correcciones, y la mayoría de nosotros lo que hacemos es crear una carpeta / copia del programa con el mismo nombre pero con terminaciones _Resp, V1, V2, y así según vallamos avanzando en el desarrollo. Esto se complica más cuando dos o más desarrolladores trabajan sobre el mismo programa, o peor, en el mismo archivo.

Los sistemas de control de versiones nos ayudan a resolver estos problemas. Estos sistemas funcionan comparando archivos a bajo nivel contra lo que tienen almacenado, de esta forma guardan el estado de cada archivo en cada versión que se ha generado, lo que nos permite hacer revisiones a través del tiempo y saber que se cambió y quien hizo el cambio.

El sistema del que vamos a comentar es Git.

Git es el sistema de versiones desarrollado por el mismo equipo que desarrolló Linux, por lo que comparte varias características y comandos, en varias distribuciones de Linux Git está instalado por defecto. Para el caso de Windows, Mac-os y otras distribuciones de Linux, el instalador se puede descargar de manera gratuita desde su sitio web (https://www.git-scm.com) ahí también encontraremos documentación y recursos relacionados. Una vez instalado el sistema, usaremos el programa Git Bash, que es la consola de Git.

Veamos cuales son los estados de un archivo en Git: 

• Untracked -> archivo que está en el directorio pero que Git no lo tiene en su sistema de control.

• Tracked -> el archivo es agregado al área stagign* de Git y es donde comienza a ser parte de los archivos controlados por Git

• Committed -> El archivo pasa del área staging al repositorio de la rama** en la que estemos trabajando.

Algunos conceptos que vamos a utilizar

• Staging es el área de Git donde guarda temporalmente el archivo en el que estamos trabajando y es desde donde compara con las versiones que ya existen en el repositorio.
• La rama principal de Git se llama "Master".

Antes de iniciar debemos de realizar algunas configuraciones  de nuestro usuario, ya que Git es una herramienta colaborativa debemos de saber exactamente quién es el responsable de cada cambio. Para ello usamos los siguientes comandos en la consola

Veamos cuales son los estados de un archivo en Git:

Para iniciar el control de versiones de nuestros programas o archivos, debemos de inicializar un repositorio, para ello debemos de abrir la consola de Git y ubicarnos en la carpeta donde están los archivos que vamos a versionar. Estando ahí ejecutamos el comando git init, los principales cambios que vamos a notar en la consola es que Git automáticamente nos coloca en la rama Master y se crea una carpeta oculta .Git que es donde Git tiene sus recursos para controlar el repositorio

Ahora que ya tenemos el repositorio en la carpeta de nuestro programa podemos empezar a agregarlos a la base de versiones. Veamos la forma en que el archivo pasa en cada uno de los estados anteriormente mencionados con los comandos de Git:

Para saber que archivos han sido modificados o no están trackeados o si el repositorio no ha tenido cambios, usamos el comando git status

Hay proyectos que tienen una gran cantidad de archivos, para agregarlos todos usamos el comando Git add .

Como vimos, el comando git add . agrega los datos a staging, para crear la primer versión del ejecutamos el comando git commit -m "Comentario del commit". El comentario es necesario para poder identificar qué es lo lleva esa versión

A cada commit Git le asigna un numero único el cual nos va a servir para poder movernos entre cada una de las versiones. Para conocer el número de los commits usamos el comando git log

O para verlo de una forma simplificada git log --oneline

Supongamos que tenemos un programa al que nos han solicitado realizar un cambio, entonces creamos la rama Desarrollo1 a partir de Master, que es la versión de producción. Durante el desarrollo nos reportan un error que se debe de corregir inmediatamente, entonces creamos una rama que se llama HotFix1 a partir de la rama Master. Para crear las ramas usamos el comando git Branch "Nombre"

Para saber que ramas tenemos ejecutamos el comando git branch, se puede ver que master está resaltado, con esto Git nos indica que el head del repositorio está apuntando a la rama master

Vamos a empezar a hacer cambios en nuestra rama Desarrollo1, para cambiar de ramas usamos el comando git checkout <nombre de la rama>

Si vemos la consola, ya no está entre paréntesis la rama Master, ahora está Desarrollo1, si ejecutamos el comando git branch ahora ya estará resaltada la rama

Vamos a nuestra aplicación y hagamos una función llamada funcionDesarrollo en un módulo existente, esta función solo mandará un mensaje a pantalla

Guardamos la aplicación y regresamos a la consola de Git, usamos el comando git status y vemos los cambios que ya encontró en el repositorio

Vemos que el sistema ya nos indica que hay archivos modificados y que debemos de llevarlos a stagign con git add ., vemos el estatus con git status y hacemos el commit en la rama Desarrollo1

Ahora vamos a cambiar a la rama HotFix1, nuevamente la consola nos indica que estamos en otra rama

Si vemos el log de HotFix1 no vamos a encontrar el commit que se hizo en Desarrollo1

Ahora veamos el programa, Visual Studio nos va a indicar que el archivo cambió y que se debe de recargar, notaremos que la función ya no existe

En esta rama vamos a modificar la función BuscaBase y creamos otra que nos envíe el nombre de la base

Guardamos el cambio, en la consola agregamos el cambio a staging y hacemos el commit

Vamos a regresar a la rama Master, Visual Studio nos va a recargar el archivo sin ninguna modificación

Lo lógico es que traigamos los cambios del HotFix1 a la rama Master, para ello usemos el comando git merge <nombre de la rama>

Veamos el log y encontraremos que ya está el commit de HotFix1 en Master

Veamos el archivo en Visual Studio

Ya se encuentra la modificación a la función BuscaBase y la nueva función nombreBase

Ahora hagamos merge con la rama Desarrollo1 y veamos que pasa

OMG!! El merge falló y la rama master quedó en un estado Merging!!

Lo que pasa es que hay conflictos en la misma línea que Git no puede resolver de forma automática, regresemos a Visual Studio y veamos cómo nos muestra los conflictos

La mayoría de los editores modernos ya nos ayudan a gestionar los conflictos, en este caso nos indica con la etiqueta

<<<<<<< HEAD

============

Lo que tenemos en la rama en la que estamos ubicados, en este caso es Master; y con la etiqueta

>>>>>>> Desarrollo1

Lo que tenemos en la rama Desarrollo1

Lo que toca hacer es resolver el conflicto de forma manual y guardar el archivo

Lo que hicimos fue dejar las dos nuevas funciones y el parámetro agregado a la función existente.

Regresemos a la consola y veamos el estatus del programa

Agregamos el archivo con git add ., y ejecutemos el commit

¿Por qué hicimos un commit? La función merge lo que hace es escribir los cambios y luego hace un commit para guardar la versión generada con el merge, al fallar el merge por el conflicto nos toca hacer el commit en un segundo paso

Ahora veamos el log

Vemos que en Master están los commits que se hicieron en HotFix1, en Desarrollo1 y el commit para resolver los conflictos

Por último usemos el comando git log --all --graph --decorate --oneline

Lo que nos muestra es una gráfica de lo que realizamos.

Estas son las funciones básicas de Git, sin embargo aún se pueden hacer muchas más cosas como:

• Importar repositorios
• Exportar repositorios
• Trabajar con repositorios remotos, usualmente con repositorios en GitHub
• Trabajar con llaves criptográficas
• Elegir commits.
• Y un considerable etc.

Hasta aquí mi colaboración a este interesantísimo blog, aprovecho para felicitar a Ana por compartirnos una de sus pasiones en la vida y ojalá que este, su blog, se siga consolidando como fuente fiable de información.

No olvide compartirnos y seguirnos en este blog o en Facebook.