Como parte de la natural evolución tecnológica en nuestros procesos de construcción de software, en Panel Sistemas nos hemos esforzado por promover y adoptar Git como principal sistema de control de versiones de código fuente. Para ello hemos estado migrando paulatinamente desde  Apache™ Subversion® (o incluso CVS), un paso que no es trivial.

A estas alturas parece no ser preciso justificar el uso de un sistema de gestión de la configuración software. Y no vamos a hacerlo.

Entre las facilidades que nos proporciona el ecosistema de herramientas OGMA se incluye la normalización de los sistemas de control de versiones que utilizamos, tanto sistemas distribuidos (DVCS) como centralizados (VCS).

Actualmente, Git es el sistema de control de versiones favorito de OGMA.

Pero OjO: utilizar Git otorga un gran poder, lo que conlleva una gran responsabilidad. El mensaje de OGMA para los que se inician en Git es claro:

«No os hagáis los héroes al empezar con Git,
formaos porque es potencialmente mortal … para todos».

¿Qué es Git ?

Un sistema de control de versiones que permite trabajar a un gran número de programadores con gran cantidad de código.

Lo primero que llama la atención es su rapidez, especialmente gestionando ramas (líneas de desarrollo independientes). La fobia a crear ramas es un mal que atenaza a los desarrolladores con frecuencia, por soler ser algo  lento. Con Git nos desprendemos de dicha traba. Podemos crear todas las ramas que hagan falta, ¿y ahora?

Libertad total no puede significar desorganización, o estaremos sustituyendo un problema por otro. Por ello nosotros hemos optado por utilizar Gitflow. Gitflow engloba una serie de criterios para la utilización de Git en proyectos software, una metodología de trabajo con Git, cuyo eje es la categorización de las diferentes ramas posibles en un proyecto y la interrelación entre las mismas.

Además, como sistema distribuido, Git también nos da la posibilidad de guardar nuestros cambios tengamos o no conexión. Cuando podamos consolidar nuestros cambios tendremos que gestionar también los conflictos. Es el delicado «momento merge».

En particular, os destacamos dos características de Git:

• Cómo maneja Git los cambios: Es un aspecto muy diferencial de Git con respecto a otros sistemas de control de versiones. En lugar de almacenar los archivos originales, conservando una lista de los cambios realizados sobre dichos archivos en cada versión, Git guarda una «foto» (snapshot) del estado de cada archivo en un momento concreto.

Si uno de los archivos no ha cambiado no crea una nueva copia del mismo, simplemente crea una referencia al archivo original.

• La eficiencia. Git se basa en que cada programador almacena una copia del repositorio necesario en su máquina de forma local, incluido el historial de cambios. Esto implica que muchas de las operaciones realizadas sobre el código fuente no tienen lugar en la red, permitiendo que la velocidad de proceso dependa únicamente en los recursos locales.

Git: Un par de consejos de amigo

Queremos compartir un par de consejos, especialmente para todos aquellos que han trabajado con sistemas de control de versiones centralizados :

CONSEJO 1

A medida que aprendas Git, debes olvidar todo lo que puedas saber sobre otros sistemas de control de versiones, como Subversion y CVS; hacerlo te ayudará a evitar confusiones sutiles (y mortales) a la hora de utilizar esta herramienta.

Git almacena y modela la información de forma muy diferente a esos otros sistemas, a pesar de que su interfaz sea bastante similar; comprender esas diferencias ayudará a evitar que te confundas a la hora de usarlo.

Olvidando el pasado – desaprender

CONSEJO 2

Muy importante: En todos los proyectos con Git como Sistema de Control de Versiones hay que trabajar por adelantado la estrategia de ramas y los flujos de entrega de código. No lo dudéis, solicitad asesoría.

Git almacena y modela la información de forma muy diferente a esos otros sistemas; comprender esas diferencias ayudará a evitar que te confundas a la hora de usarlo.

A saber: La tres áreas de trabajo o estados en Git

Esto es lo más importante a recordar acerca de Git si queremos que el resto de nuestro proceso de aprendizaje prosiga sin problemas.

En Git los archivos tienen tres estados principales en los que se pueden encontrar: confirmado (committed), modificado (modified), y preparado (staged):

• Confirmado significa que los datos están almacenados de manera segura en tu base de datos local.
• Modificado significa que has modificado el archivo pero todavía no lo has confirmado a tu base de datos.
• Preparado significa que has marcado un archivo modificado en su versión actual para que vaya en tu próxima confirmación.

Esto nos lleva a las tres secciones principales de un proyecto de Git:

• El directorio de Git (Git directory) es donde Git almacena los metadatos y la base de datos de objetos para tu proyecto. Es la parte más importante de Git, y es lo que se copia cuando clonas un repositorio desde otro ordenador.
• El directorio de trabajo (working directory) es una copia de una versión del proyecto. Estos archivos se sacan de la base de datos comprimida en el directorio de Git, y se colocan en disco para que los puedas usar.
• El área de preparación (staging area) o índice es un sencillo archivo, generalmente contenido en tu directorio de Git, que almacena información acerca de lo que va a ir en tu próxima confirmación.

Para terminar, el flujo de trabajo básico en Git es de este estilo:

1. Modificas una serie de archivos en tu directorio de trabajo.
2. Preparas los archivos, añadiendo instantáneas de ellos a tu área de preparación o índice.
3. Confirmas los cambios, lo que toma los archivos tal y como están en el área de preparación, y almacena esa instantánea de manera permanente en tu directorio de Git.

En resumen, si una versión concreta de un archivo está en el directorio de Git, se considera confirmada (committed). Si ha sufrido cambios desde que se obtuvo del repositorio, pero ha sido añadida al área de preparación, está preparada (staged). Y si ha sufrido cambios desde que se obtuvo del repositorio, pero no se ha preparado, está modificada (modified).

1,2,3 y ¡a volar!

Si necesitas descubrir Git desde cero, nada como visitar directamente su web o – mejor aún – descargar su cliente y probarlo personalmente. Como todo entra mejor por la vista, puedes probar a utilizarlo con algún cliente gráfico porque siempre ganarás en comodidad y visión de conjunto, aunque su potencial será más limitado que la consola de comandos. Nosotros utilizamos en estos momentos Source Tree, cortesía de Atlassian.

Por nuestra parte, debemos recalcar que la máxima productividad software la conseguiremos alineando la cultura del equipo, los procesos con los que fabricamos el software y el uso que hacemos de las herramientas adecuadas, como Git.

Una vez más, como escribiente, 
mi más sincero agradecimiento 
a José Turégano y a Javier Arance 
por su esfuerzo en la difusión del conocimiento,
del que este artículo es una muestra.

«Git-logo» por Jason Long - http://git-scm.com/downloads/logos.
 Disponible bajo la licencia CC BY 3.0 vía Wikimedia Commons