Introducción

Cada operación de Git mueve datos entre tres áreas: el árbol de trabajo (tus archivos), el index (borrador del próximo commit) y el repositorio (historial commiteado bajo .git). Nombrar lo que se mueve a dónde es el modelo mental más útil.

Introducción

Un branch de seguimiento remoto es una ref local que refleja un branch en un remoto. Viven bajo refs/remotes/<remote>/ y se actualizan por git fetch (y operaciones que implican fetch, como git pull y git clone). No haces commit directamente a ellos.

De dónde vienen

El refspec predeterminado para origin es:

Introducción

Normalmente HEAD apunta a una ref de branch, que a su vez apunta a un commit. En HEAD desconectado, HEAD apunta directamente a un commit. HEAD desconectado no está roto; es un modo deliberado que es útil para inspeccionar el historial y peligroso para commitear sin pensar.

Introducción

El reflog registra cada cambio a HEAD y a la punta de cada branch en tu máquina local. Es local, por clon y no se pushea. Casi cualquier commit "perdido" puede rescatarse a través de él.

Introducción

Git tiene dos resultados de merge fundamentalmente diferentes: fast-forward, donde la punta de un branch simplemente se mueve, y three-way, donde se crea un nuevo commit con dos padres. La elección depende de si los branches han divergido.

Fast-forward

Si la punta de main es ancestro de feature, no se necesita un merge real. Git solo mueve main hacia adelante:

Introducción

En Git, un branch es solo una referencia móvil a un commit. Crear un branch es crear un archivo de 41 bytes. Comparado con sistemas centralizados donde los branches son copias completas de directorio, el modelo de Git hace el branching lo suficientemente barato para usarlo casualmente.

Qué es realmente un branch

cat .git/refs/heads/main
# a1b2c3d4e5f6...
git rev-parse main

Ese hash es la punta del branch. El "branch" en sí es la cadena de commits alcanzables desde la punta vía punteros padre.

Introducción

El index es un archivo binario en .git/index que refleja un objeto tree: una lista ordenada de paths con mode, hash e información stat. Es el área de staging para el próximo commit y un caché que permite a Git saltarse el rehasheo de archivos sin cambios.

Inspeccionándolo

git ls-files --stage
# 100644 a1b2c3...  0  README.md
# 100644 e4f5g6...  0  src/main.c

El stage 0 significa "sin conflicto". Durante un merge, los paths conflictivos obtienen los stages 1 (base), 2 (ours), 3 (theirs).

Introducción

Los objetos son inmutables y nombrados por hash. Las referencias son los nombres mutables y legibles que apuntan a ellos. Cada branch, tag, branch de seguimiento remoto y HEAD es una ref.

Dónde viven las refs

Las refs son archivos (o entradas en el archivo packed-refs) bajo .git/refs/:

Introducción

Git nombra cada objeto por el hash criptográfico de su contenido. Esto es almacenamiento direccionado por contenido: el nombre es la huella digital del contenido. El hash predeterminado es SHA-1 (160 bits, 40 caracteres hex). El soporte SHA-256 existe experimentalmente desde Git 2.29.

Cómo se calcula un hash

Git antepone una cabecera de la forma <type> <size>\0 al contenido crudo, luego hashea:

Introducción

El repositorio de Git es, en esencia, un almacén de objetos direccionado por contenido. Hay exactamente cuatro tipos de objetos: blob, tree, commit y tag. Cada operación eventualmente toca alguno de ellos. Entender estos cuatro tipos desmitifica la mayor parte de Git.

Blobs

Un blob almacena el contenido de un archivo, nada más. Sin nombre, sin permisos, sin historial. Dos archivos con contenido idéntico comparten un blob, sin importar dónde vivan en el árbol.