Cuatro tipos de objetos

Git almacena todo como objetos direccionados por contenido bajo .git/objects. Hay cuatro tipos: blob (contenido de archivo), tree (listado de directorio de blobs y subtrees), commit (puntero de instantánea con autor, committer, mensaje y padres), y tag (tag anotado con firmante y mensaje). Cada uno se nombra por el SHA-1 (o SHA-256) de su contenido.

El problema que resuelven los worktrees

Estás a mitad de feature cuando llega una solicitud urgente de hotfix. Hacer stash o cambiar de contexto es arriesgado y lento. Los worktrees te dejan hacer checkout de ramas adicionales en directorios separados, todos compartiendo una base de datos de objetos subyacente. Cada worktree tiene su propio HEAD, índice y árbol de trabajo.

El caso de la firma SSH

GPG es potente pero operativamente doloroso. Desde Git 2.34, puedes firmar commits y tags con las llaves SSH que ya usas para hacer push. Sin keyring, sin malabarismos de passphrase, sin red de confianza separada. GitHub, GitLab, Gitea y Forgejo aceptan commits firmados con SSH.

Por qué firmar

Un commit firmado atestigua criptográficamente "este commit fue autorizado por el poseedor de esta llave, sin cambios desde la firma." Las firmas defienden contra suplantación y manipulación, y plataformas como GitHub muestran un badge "Verified" cuando la firma coincide con una llave configurada.

Qué hace gitattributes

.gitattributes aplica configuraciones por ruta: finales de línea, drivers de diff y merge, filtros de export, declaraciones de codificación. A diferencia de .gitignore, los attributes aplican a archivos rastreados y son honrados por todo el equipo.

Finales de línea

# .gitattributes
* text=auto
*.sh text eol=lf
*.bat text eol=crlf
*.png binary

Tras añadir este archivo, ejecuta git add --renormalize ..

Por qué diffs personalizados

El diff predeterminado de Git es línea por línea de texto. Para formatos binarios (PDF, DOCX, imágenes) y texto estructurado donde los diffs por línea no son útiles (JS minificado, dumps SQL generados), los drivers de diff personalizados producen algo que los humanos pueden leer.

Estrategias vs drivers

Una estrategia de merge decide cómo Git combina dos historias — ort (predeterminada desde Git 2.34), recursive (legacy), resolve, octopus y ours. Un driver de merge es lógica por archivo que se ejecuta cuando ambos lados han cambiado el mismo archivo.

Después del hecho

Donde los hooks de tiempo de commit dan forma a los commits, los hooks de esta página reaccionan a ellos. post-commit se ejecuta localmente tras cada commit, pre-push se ejecuta antes de transferir objetos a un remote, y post-receive se ejecuta en el servidor tras aterrizar un push.

post-commit

No puede bloquear — se ejecuta tras registrarse el commit. Útil para notificaciones, regeneración de ctags, o lanzar tareas en background.

Hooks del lado cliente

Los hooks son scripts ejecutables en .git/hooks/ (o donde apunte core.hooksPath). Git los invoca en momentos bien definidos. Los tres hooks de tiempo de commit te permiten aplicar políticas antes de que un commit sea finalizado.

pre-commit

Se ejecuta antes de que se componga el mensaje del commit. Devuelve no-cero para abortar. Usos típicos: linting, formato, escaneo de secretos, ejecutar tests rápidos.

Qué hace rerere

Rerere — "reuse recorded resolution" — observa cómo resuelves un conflicto de merge, registra la resolución, y la reproduce la próxima vez que el mismo conflicto aparezca. Es invaluable en ramas de larga vida que repetidamente hacen rebase o merge contra un main activo.