Control de versiones con Git (I)

Cualquier programa, no importa si se ejecuta en nuestro ordenador o en un servidor, está formado por un conjunto de instrucciones que le dicen como tiene que hacer las cosas. Esas instrucciones, que se escriben en un archivo de texto, no se pueden ejecutar directamente en el ordenador. Hace falta un paso extra (llamado compilación) que usa esos archivos de texto para generar código máquina. El código máquina es lo que realmente ejecuta el ordenador y es de muy bajo nivel. Podemos usar muchos lenguajes de programación. Algunos compilan los archivos de texto (el código fuente) en un ejecutable que funciona directamente en el ordenador. Otros generan un código intermedio que necesitan de un elemento extra para funcionar. De momento no quiero entrar en las diferencias ya que se queda fuera del objetivo de esta entrada. El elemento común a todos los lenguajes es que el código fuente es un archivo de texto. Las instrucciones se escriben en ese archivo de texto. Cuando programamos, una herramienta vital es el control de versiones. Simplificando un poco, el control de versiones apunta los cambios que sufre un archivo de código fuente. Las líneas que añadimos, modificamos o borramos se apuntan en un histórico. Al hacerlo de esta forma es posible volver al contenido del archivo en cualquier momento.

Logo de Git

Conceptos básicos

Al principio puede parecer que el control de versiones no nos aporta nada cuando programamos una aplicación. Ésto es cierto es programas muy sencillos y siempre que trabajemos solos. En esos casos se puede seguir la política de guardar los archivos con un nombre nuevo conforme avanzamos en la programación. Desgraciadamente, hay varios problemas que no estamos teniendo en cuenta:

• Si la aplicación dura y le dedicamos tiempo, acabaremos con muchos archivos tipo “- copia fecha”.
• Para volver a una versión anterior hay que recordar la fecha de la última modificación y recuperar de forma manual el archivo.
• Podemos tener cambios que nos interese mantener y cambios que haya que deshacer.
• Si trabajan varias personas en el programa, la complejidad para conocer los cambios y la versión en la que se han realizado aumenta.

Todos estos problemas aparecen con programas sencillos. Si son complejos, con muchos archivos de código fuente, el problema crece en complejidad. Pasaríamos más tiempo gestionando de forma manual los cambios que trabajando en el código fuente.

Los repositorios en Git

Podemos usar una gran variedad de sistemas de control de versiones. Cada uno tiene sus ventajas e inconvenientes. Conviene conocer las diferencias antes de empezar ya que nos ahorrarán dolores de cabeza a futuro. En la actualidad, Git es uno de los más usados ya que es sencillo de usar y no obliga a descargar todo el código de una aplicación. A continuación veremos los conceptos básicos que necesitamos conocer antes de empezar a trabajar.

Archivos originales de la carpeta

Un repositorio es una carpeta normal que incluye una serie de archivos / carpetas ocultas. Esa información es la que permite a Git detectar los cambios y guardar el estado de los archivos. Normalmente no se modifican los archivos de forma manual y hay que usar comandos de Git para evitar problemas. Cada vez que añadamos una función o arreglemos un bug, haremos un commit. El commit es una forma de decirle al control de versiones que guarde los cambios de todos los archivos del repositorio.

Archivos ocultos de Git

Ésto nos permite ver las líneas que se han modificado para trabajar en esa incidencia (issue). De esa forma se pueden comprobar los cambios de forma más rápida. Hay ocasiones que los cambios afectan a varios elementos y provocan daños colaterales. Al poder revisar de forma rápida los cambios, se simplifica mucho encontrar la causa del problema.

Archivos dentro la carpeta de Git

Cada repositorio cuenta como un proyecto de software. No podemos tener un repositorio dentro de otro.

Las ramas de trabajo en Git

Si tenemos un programa que distribuimos a los usuarios finales, no es práctico crear un ejecutable cada vez que añadamos una función. Es importante recordar que pueden aparecer fallos y el usuario saldrá corriendo si cada vez que actualiza el programa tiene un problema nuevo. Para evitar este problema tenemos las ramas de trabajo. Mientras que el commit nos permite guardar el estado de los archivos del código fuente, la rama se puede ver como una agrupación de commits. Supongamos que tenemos dos ramas: master (producción) y develop (desarrollo). En la primera rama tenemos el código probado y es la que usan los usuarios. En la segunda se van añadiendo las funciones nuevas y se van probando durante un tiempo. Cuando el programador responsable considera que el código es estable, se pasa a master y se genera el ejecutable que usará el usuario final.

Ejemplo de histórico en Git

Normalmente el programador trabaja sobre la rama de develop. Cuando define una incidencia nueva, para añadir una función o corregir algo, crea una nueva rama tomando como base la rama de develop. Ésto que puede parecer redundante tiene sentido cuando se trabaja en equipo. En la rama nueva tendremos todos los cambios que nos permiten arreglar la incidencia. Mientras se trabaja se van creando commits en puntos concretos para ganar en salud mental. Cuando finalizamos integramos la rama nueva en la rama de desarrollo.

Conclusiones

En esta entrada hemos visto una pequeña introducción al control de versiones. Espero que no haya sido muy densa pero es importante conocer los conceptos básicos. Me he tomado algunas licencias en la explicación de los conceptos básicos para que fueran más sencillos de entender. En la siguiente entrega lo veremos de forma más gráfica usando GitLab. Aunque Git se puede usar mediante consola o con una aplicación gráfica, los cambios se quedan siempre en nuestro ordenador. Si nos interesa compartir el código con otros usuarios, una opción es guardar el repositorio en un servidor como GitLab o GitHub. Hay muchas ventajas en hacerlo de esta forma. También es posible, en el caso de GitLab, instalar el servidor en una máquina de nuestra red y aprovechar todas las ventajas que nos ofrece en la versión Community.