La tradición mailbox

git am aplica parches en formato mbox: el formato usado por proyectos dirigidos por listas de correo como el kernel de Linux y Git mismo. Cada entrada mbox contiene un parche más sus metadatos de commit (autor, asunto, cuerpo).

Por qué parches

Los parches son diffs portables que puedes enviar por correo, pegar en un ticket o guardar como archivo. Así funciona el desarrollo del kernel de Linux a escala y siguen siendo útiles cuando necesites compartir un cambio sin acceso de push a un remote compartido.

Un flujo, no un pánico

Los conflictos son rutina. El flujo correcto los convierte de un evento de estrés en una tarea de cinco minutos: inspeccionar, decidir, editar, verificar, continuar.

Qué es tres-vías

El diff de dos vías muestra qué cambió entre dos versiones. El diff de tres vías también considera el ancestro común, dejando que Git decida si una región fue cambiada por un lado, el otro o ambos. Tres vías es la base del merge.

Inspeccionar un conflicto

<<<<<<< HEAD
nuestra versión
=======
su versión
>>>>>>> feature

Mostrar los tres lados:

Las pseudo-refs poco celebradas

Más allá de HEAD, Git mantiene un pequeño zoológico de refs actualizadas automáticamente que registran lo que acaba de pasar. Conocerlas convierte "borré mi trabajo" en una recuperación de una línea.

HEAD

Apunta a la branch actual (e.g., ref: refs/heads/main) o, cuando está desacoplado, a un SHA de commit directamente.

ORIG_HEAD

Establecida por operaciones destructivas (merge, rebase, reset, am) al tip anterior. La recuperación clásica:

Más allá del predeterminado

git log es un pequeño lenguaje de consulta para tu historia. Con los flags adecuados produce reportes calidad dashboard, registros de auditoría y forenses de bugs.

Formatos pretty

git log --pretty=oneline
git log --pretty=fuller
git log --pretty=format:'%h %ad %an %s' --date=short
git log --pretty=format:'%C(yellow)%h%Creset %C(cyan)%ad%Creset %s %C(green)(%an)%Creset' --date=short

Define un alias permanente:

Editar la historia sin reescribirla

A veces quieres empalmar historias (un import de Subversion convertido encontrándose con una continuación, por ejemplo) sin reescribir commits. Los grafts y el namespace refs/replace/ le permiten a Git fingir que el padre de un commit es un commit diferente, dejando los objetos originales intactos.

Grafts (legacy)

.git/info/grafts es un archivo de texto plano: cada línea especifica los padres de un commit. Los grafts están obsoletos en favor de replace refs porque son solo locales y confusos.

El área de staging, desmitificada

El índice (alias cache, área de staging) vive en .git/index como archivo binario que describe lo que contendrá el próximo commit. No es un tree — es una lista plana ordenada de entradas de ruta con stat info, modo y SHA. Operaciones como git add, git rm y git mv actualizan el índice; git commit lo convierte en un objeto tree.

Qué es una ref

Una ref es un nombre que apunta a un objeto — usualmente un commit. Las branches son refs bajo refs/heads/, los tags bajo refs/tags/, los remote-tracking bajo refs/remotes/, y pseudo-refs como HEAD, FETCH_HEAD, ORIG_HEAD viven en la raíz de .git.

Fundamentos de packfile

Un packfile agrupa muchos objetos en un archivo con compresión delta — en lugar de almacenar cada versión de un archivo completa, los objetos similares comparten una base y solo guardan la diferencia. El resultado es una reducción de tamaño 5x a 50x en repos reales.