¿Cómo funciona Git internamente?

Question

Accepted Answer

Internamente, Git es un **almacén de objetos direccionables por contenido** — almacena todo como **objetos** (blobs, árboles, commits, etiquetas) identificados por su **hash SHA-1**. Comprender este modelo desmitifica Git y explica por qué sus operaciones se comportan como lo hacen.

## Por qué es importante

```text
Git stores 4 types of OBJECTS, each identified by the SHA-1 HASH of its content:
  BLOB   → file CONTENTS (just the data, no filename)
  TREE   → a directory: maps names → blobs (files) and trees (subdirs) + permissions
  COMMIT → a snapshot: points to a TREE (the root) + parent commit(s) + author/message
  TAG    → an annotated tag object (points to a commit, with metadata)
→ Content-addressable: an object's ID IS the hash of its content (same content = same hash).
```

## Un commit es una instantánea, no un diff

```text
→ Each COMMIT points to a complete TREE (the full state of the project at that point)
→ Git stores SNAPSHOTS, not diffs (though it compresses/deduplicates internally):
  unchanged files → the commit's tree just REUSES the same blob (same hash) → efficient
→ Diffs you see are COMPUTED between snapshots, not stored.
```

## Cómo encaja todo junto

```text
Branch (e.g. main) → a pointer (a ref) to a COMMIT
HEAD → points to the current branch (or commit)
Commit → tree → blobs (the snapshot)
Commit → parent → parent → ... (the history chain)
→ Branches/tags are just small files containing a commit hash (cheap pointers).
  That's WHY branching is so lightweight.
```

## Por qué esto explica el comportamiento de Git

```text
✓ Branches are cheap → they're just a 40-char hash in a file (not file copies)
✓ Integrity → content-addressing means corruption/changes are detectable (hash mismatch)
✓ Commits are immutable → changing anything = a new hash = a new commit (why rebase
  creates NEW commits, why history rewriting changes hashes)
✓ Deduplication → identical content stored once (shared blobs)
```

## Por qué es importante

Comprender cómo funciona Git internamente es conocimiento valioso de nivel senior porque **desmitifica Git** y explica *por qué* sus operaciones se comportan como lo hacen, profundizando tu capacidad de razonar sobre Git y usarlo con confianza.

El modelo central — Git como un **almacén de objetos direccionables por contenido** con cuatro tipos de objetos (blobs para contenidos de archivo, árboles para directorios, commits para instantáneas, etiquetas) cada uno identificado por el **hash de su contenido** — es la base sobre la que descansa todo lo demás.

Comprender que **un commit es una instantánea, no un diff** (cada commit apunta a un árbol completo que representa el estado completo del proyecto, con archivos sin cambios reutilizando eficientemente los mismos blobs, y los diffs se calculan en lugar de almacenarse) corrige una idea errónea común y explica el modelo basado en instantáneas de Git.

Ver **cómo encaja todo junto** (ramas y etiquetas como punteros/refs baratos a commits, HEAD apuntando a la rama actual, commits encadenados vía padres) revela la elegante simplicidad subyacente.

Más valiosa aún, esta comprensión **explica el comportamiento observable de Git**: por qué las **ramas son ligeras** (solo un hash en un archivo pequeño, no copias de archivo — explicando por qué la ramificación es tan rápida), por qué Git tiene **integridad** (el direccionamiento por contenido detecta corrupción mediante desajustes de hash), por qué los **commits son inmutables** y las operaciones de reescritura de historial como rebase crean **nuevos commits con nuevos hashes** (cambiar cualquier contenido cambia el hash), y por qué Git **desduplica** (el contenido idéntico se almacena una sola vez).

Este modelo más profundo transforma Git de un conjunto de comandos memorizados en un sistema comprensible, permitiendo razonamiento seguro sobre operaciones complejas.

Ya que comprender el modelo interno de objetos explica por qué Git se comporta como lo hace (ramas ligeras, commits inmutables, cambios de hash al reescribir, integridad) y eleva a uno de usar Git a realmente comprenderlo, comprender los internals de Git es conocimiento valioso de nivel senior — un tema que refleja la profundidad esperada para roles senior y proporciona el modelo mental para razonar sobre Git con confianza, desmitificando su comportamiento y haciendo que las operaciones avanzadas sean comprensibles en lugar de misteriosas.