Cuando hace un año me puse a hacer una pequeña revisión (guiño involuntario..) de los sistemas de control de versiones existentes y populares, tardé muy poco en darme cuenta de cuál era el verdadero VCS que lo estaba petando.

Git es el nuevo dueño. Subversion llegó para comerse CVS. Git simplemente estando ahí, los ha devorado a todos. Por qué?

Resumiendo, porque es un sistema descentralizado. O puede serlo. O puede ser centralizado. Git es lo que tu quieras que sea. Un repositorio Git no está en un servidor donde tu haces commits y checkouts, aunque podría. Para aclarar un poco este lío, voy a intentar explicar el funcionamiento básico de Git, y porque se diferencia esencialmente de Subversion et al.

Un repositorio Git es un directorio situado en la raíz del directorio de trabajo (me estoy planteando dejar de traducir aleatoriamente y empezar a hablar de las cosas por su nombre: working directory). Éste contiene toda la información sobre los ficheros del repositorio, tanto en su versión actual como todo su historial. Cada revisión de un documento se almacena tal cual, como un objeto más, identificado por un nombre de 40 caracteres que se obtiene por una función de hash SHA1. Con lo de “tal cual” me refiero a que no se basa en diferenciales entre versiones (como hace Subversion), sino que cada versión de un fichero se almacena íntegramente. Sorprendentemente esto es eficiente en espacio y tiempo!

En resumen: cada proyecto en el que usemos Git tendrá un directorio en su raíz (por defecto llamado .git), que contendrá todo lo que haya pasado por el proyecto. Esto es la descentralización: no tenemos ninguna dependencia con un servidor. Podemos estar trabajando un mes offline, y luego sincronizar con el servidor.

Ah, pero hay servidor?

Puede haberlo. Aunque Git sea brutalmente útil en trabajos en solitario, “com més serem, més riurem”. Como he dicho, cada copia local de un repositorio Git es válida por si misma, y no necesita de ningún servidor, aunque Git nos ofrece la posibilidad de mandar mensajes entre copias del mismo repositorio y “sincronizarse” por decirlo de alguna forma. Así que si queremos, podemos sustituir fielmente la estructura de un servidor SVN con sus usuarios haciendo commits / checkouts a él, por un repositorio Git almacenado en un servidor y varias copias de éste que hagan push / pull cuando tengan cambios.

Prometedor, y aún no he nombrado la killer feature de Git: branch & merge. Cuántas veces has creado una rama (odio traducir! quiero decir branch, se llama branch, pero si no traduzco, parece que estemos en Puerto Rico (no offense!)) en un repositorio Subversion/CVS? Yo sólo un par de veces. Usando Git en una docena de proyectos, ya he creado (y luego fusionado casi todas ellas) unas 50 ramas (branches, sí). Precisamente debido a la descentralización de Git, puedes estar trabajando en un proyecto dónde hay un servidor, dónde mas gente participa, y querer implementar una nueva característica que va a afectar muchos ficheros a la vez (no siempre aislamos suficientemente el código..). Intentar hacerlo “de un sólo commit” (como diría el Sastrecillo Valiente), no es muy sensato. Así que hacemos un branch (me he hartado) en nuestro ordenador, empezamos a meter mano al código, y si al cabo de 40 commits no funciona nada, nos cargamos el branch. Si llegamos a buen puerto, en cambio, podemos hacer fusionar  el nuestro con el repositorio del servidor, y nuestros cambios ya estarán disponibles para el resto del equipo! Y lo mejor de todo, es muy fácil hacer un merge aún cuando otros han ido modificando el código mientras nosotros trabajábamos, haciendo un rebase y obteniendo nosotros los cambios del resto del equipo para mezclarlos con nuestro branch, para ver si son compatibles (si no lo son, solucionar los conflictos) y entonces fusionarnos sin colisiones. Easy as pie.

Aunque los detalles de branching & merging parezcan confusos (no es trivial explicar su funcionamiento en cuatro líneas), es muy sencillo y potente. Recomiendo las siguientes lecturas para profundizar en el tema, y los que no estéis usando Git hagáis el paso cuando no podáis aguantar más:

• Git Internals – Scott Chacon, PDF, $9 bien invertidos
• The Git Community Book – Página oficial de Git
• Starting with Git – Sirupsen’s Blog