La revelación: el almacén está debajo, no dentro

Casi todo el mundo aprende Git por su superficie: se hace un commit, se cambia de rama, se fusiona, y cuando algo sale mal se busca en la red el conjuro que lo arregla. Bajo esa superficie hay una arquitectura que rara vez se enuncia con precisión, y enunciarla bien cambia por completo lo que uno entiende del sistema. La formulación habitual dice que Git es un control de versiones que guarda las cosas en un almacén interno. La formulación correcta invierte los términos: Git es un almacén direccionado por contenido, y el control de versiones es una interfaz construida sobre él. La diferencia no es retórica ni pedagógica. Determina qué operaciones son baratas, cuáles son peligrosas, qué se puede replicar sin coordinación y qué exige acuerdo. Esta lección no pide creer en esa inversión: la demuestra con los comandos que el propio Git expone para manipular el almacén sin pasar por la interfaz, y termina construyendo un commit válido sin usar nunca el comando de hacer commits.

Fontanería e interfaz: dos vocabularios en el mismo programa

Git divide sus comandos en dos familias y lo hace de forma explícita en su propia documentación. La familia de interfaz, la que se usa a diario, está pensada para personas: acepta abreviaturas, adivina intenciones, imprime mensajes con consejos y cambia su salida entre versiones porque su contrato es con el usuario. La familia de fontanería está pensada para programas: su salida es estable, su entrada es estricta y sus operaciones son mínimas. Es esta segunda familia la que deja ver la arquitectura, porque cada uno de sus comandos hace exactamente una cosa del almacén y ninguna de la interfaz.

El punto de partida es el directorio .git/objects. Ahí no hay ficheros con nombres reconocibles, ni versiones numeradas, ni diferencias entre revisiones. Hay directorios de dos caracteres hexadecimales, y dentro de cada uno, ficheros cuyo nombre son los treinta y ocho caracteres restantes de un identificador. Ese identificador no lo asigna nadie: se calcula a partir del contenido que se va a guardar. Un almacén así se llama direccionado por contenido, y la propiedad que lo define es que la dirección de un dato no es un lugar donde alguien decidió ponerlo, sino una consecuencia de lo que el dato es.

mkdir /tmp/almacen && cd /tmp/almacen
git init -q -b main
git config user.email "tu@ejemplo.org"
git config user.name "Tu Nombre"

# Guardar contenido en el almacen sin tocar el arbol de trabajo
echo "hola" | git hash-object -w --stdin
# 5c1b14949828006ed75a3e8858957f86a2f7e2eb

ls .git/objects/5c/
# 1b14949828006ed75a3e8858957f86a2f7e2eb

La ruta partida en dos caracteres no es una excentricidad estética sino una concesión al sistema de ficheros. Muchos sistemas degradan notablemente cuando un directorio contiene cientos de miles de entradas, y repartir los objetos en doscientos cincuenta y seis subdirectorios mantiene cada uno en un tamaño manejable. Es la primera aparición de un patrón que recorre todo el nivel: el modelo lógico es limpio y el almacenamiento hace concesiones al mundo real, pero las concesiones nunca se filtran hacia arriba porque nada del modelo depende de dónde acabó cada byte.

Merece la pena detenerse en lo que acaba de ocurrir, porque es más raro de lo que parece. No se ha creado un fichero en el proyecto, no se ha registrado un cambio, no se ha declarado una intención. Se ha metido una secuencia de bytes en un almacén y el almacén ha devuelto la única dirección posible para esa secuencia. Si se repite el comando con el mismo contenido, el resultado es idéntico y no se escribe nada nuevo, porque el objeto ya está. La escritura es idempotente por construcción, no por cuidado del programador.

El identificador no es un número mágico

Conviene desactivar la mitología del hash cuanto antes, porque mientras el identificador parezca magia el resto del sistema seguirá pareciendo magia. Git guarda un objeto formando primero una cabecera con el tipo, un espacio, el tamaño en bytes y un byte cero, y a continuación el contenido íntegro. El identificador es el resumen criptográfico de esa concatenación. Nada más. Se puede calcular con herramientas ajenas a Git y comprobar que coinciden.

# El calculo que hace Git, hecho a mano
printf 'blob 5\0hola\n' | sha1sum
# 5c1b14949828006ed75a3e8858957f86a2f7e2eb  -

# El mismo calculo, hecho por Git
echo "hola" | git hash-object -t blob --stdin
# 5c1b14949828006ed75a3e8858957f86a2f7e2eb

Que el algoritmo sea sustituible refuerza el argumento en lugar de debilitarlo: un repositorio puede crearse con resumen de 256 bits con git init --object-format=sha256, y entonces los identificadores son otros pero la arquitectura es exactamente la misma. Lo que importa no es qué función se use sino que la dirección se derive del contenido. De ahí salen tres consecuencias que ninguna capa superior tiene que implementar: la deduplicación es automática, porque dos contenidos iguales ocupan una sola entrada; la verificación es local, porque cualquiera puede recalcular la dirección y comprobar que el dato no se corrompió; y la copia entre máquinas no necesita renombrar nada, porque el nombre viaja con el dato.

La verificación local merece un momento más de atención porque es una propiedad rara y valiosísima. En casi cualquier otro almacén, comprobar que un dato no se ha corrompido exige compararlo con otra copia o confiar en una suma de control que alguien guardó aparte y que a su vez podría estar corrompida. Aquí la comprobación es intrínseca: el nombre del objeto es su propia suma de control, y no hay forma de tener el objeto sin tener el medio de verificarlo. Un disco que empieza a fallar se detecta sin comparar con nadie y sin conexión, que es exactamente la situación en la que se encuentra un dispositivo local-first.

# Inspeccionar cualquier objeto sin saber nada de ramas ni commits
git cat-file -t 5c1b14949828006ed75a3e8858957f86a2f7e2eb   # blob
git cat-file -s 5c1b14949828006ed75a3e8858957f86a2f7e2eb   # 5
git cat-file -p 5c1b14949828006ed75a3e8858957f86a2f7e2eb   # hola

Un commit sin usar el comando de hacer commits

La demostración definitiva de que la interfaz está encima y no dentro consiste en prescindir de ella por completo. Vamos a producir un commit alcanzable desde una rama, indistinguible de cualquier otro, sin escribir jamás git commit. Cada paso toca una sola pieza: el contenido, el listado de nombres, el registro histórico y el puntero.

cd /tmp/almacen

# 1. El contenido entra en el almacen y devuelve su direccion
BLOB=$(echo "hola" | git hash-object -w --stdin)

# 2. Un listado que asocia un nombre a esa direccion
git update-index --add --cacheinfo 100644,$BLOB,saludo.txt
ARBOL=$(git write-tree)

# 3. Un registro historico que apunta a ese listado
COMMIT=$(git commit-tree $ARBOL -m "primero")

# 4. Un puntero mutable que apunta a ese registro
git update-ref refs/heads/main $COMMIT

git log --oneline
git cat-file -p HEAD

Lo que aparece al final es un repositorio normal, con su rama, su historia y su contenido, y sin embargo no se ha ejecutado ni un solo comando de la capa de interfaz. Cada uno de los cuatro pasos ha hecho algo distinto y la diferencia entre ellos es el núcleo de este nivel: los tres primeros añaden objetos inmutables a un almacén y son intrínsecamente seguros, porque añadir un objeto nunca destruye otro; el cuarto modifica un puntero, y ahí sí se puede perder algo, porque el valor anterior deja de estar apuntado por nadie.

flowchart TB
A[interfaz para personas commit merge rebase] --> B[capa de referencias mutables]
B --> C[almacen direccionado por contenido]
C --> D[objetos inmutables cuya direccion es su resumen]
A -.-> E[cambia entre versiones]
C -.-> F[formato estable y verificable]
style C fill:#a6e3a1,color:#11111b
style B fill:#f9e2af,color:#11111b

Vale la pena insistir en el orden de los pasos porque no es arbitrario y se repite en todo el sistema. Nunca se apunta a algo que no exista todavía: el blob existe antes de que el árbol lo nombre, el árbol existe antes de que el commit lo referencie y el commit existe antes de que la rama apunte a él. Esa disciplina de construir de abajo hacia arriba y publicar al final es la que garantiza que en ningún instante intermedio haya una referencia colgando, y es la misma razón por la que una sincronización interrumpida a media transferencia deja el repositorio del receptor exactamente como estaba: los objetos llegaron, pero como la referencia no se movió, no forman parte de nada.

Qué gana y qué pierde el sistema con esta forma

La tercera tarjeta es la que más pesa cuando el sistema deja de ser un experimento. Que copiar objetos no requiera negociar nombres significa que la fusión de dos almacenes es la operación de conjuntos más aburrida que existe: se vuelcan los objetos de uno en el otro y ya está, sin comparar, sin resolver, sin preguntar quién llegó antes y sin posibilidad de que algo quede a medias. En un sistema con identificadores asignados por alguien, ese mismo paso exige una tabla de traducción, una política para los choques y una forma de propagar las traducciones a todo lo que apuntaba a los identificadores antiguos. Es la diferencia entre una tarde y un trimestre.

Esta última tarjeta anticipa la tercera lección y conviene dejarla planteada ya. Cuando alguien dice que un comando de Git le borró el trabajo, casi nunca es cierto en el sentido literal: los objetos siguen en el almacén y suelen ser recuperables durante semanas. Lo que ocurrió es que un puntero se movió y dejó de haber un camino que llegara hasta ellos. Perder el camino y perder el dato son cosas distintas, y confundirlas es lo que hace que Git parezca impredecible.