Por Anónimo (no verificado) , 29 Abril 2026

Introducción

La merge base de dos commits es su mejor ancestro común: la base que Git usa para los merges three-way. Elegir la base correcta es lo que hace que los merges "automáticos" realmente funcionen.

Por Anónimo (no verificado) , 29 Abril 2026

Introducción

Cuando Git no puede combinar automáticamente dos cambios en la misma región de un archivo, deja marcadores de conflicto en la copia de trabajo y te permite resolver manualmente. Los marcadores no son magia; registran exactamente lo que cada lado hizo respecto a una base común.

Por Anónimo (no verificado) , 29 Abril 2026

Introducción

git push sube commits a un remoto y actualiza las refs de ese remoto. A diferencia de fetch, modifica el estado en el servidor, así que existen mecanismos de seguridad para prevenir sobrescribir el trabajo de otras personas.

Por Anónimo (no verificado) , 29 Abril 2026

Introducción

git pull es azúcar para git fetch seguido de la integración del branch upstream en el branch actual. El paso de integración es ya sea un merge (predeterminado) o un rebase.

Los dos pasos

  1. git fetch <remote> <refspec>: descargar y actualizar refs de seguimiento.
  2. Si pull.rebase es false: git merge FETCH_HEAD.
  3. Si pull.rebase es true: git rebase FETCH_HEAD.

Secuencia manual equivalente:

Por Anónimo (no verificado) , 29 Abril 2026

Introducción

git fetch es la operación de red que descarga nuevos objetos y actualiza las refs de seguimiento remoto. No cambia tus branches ni tu árbol de trabajo, lo que lo hace el comando "¿qué hay nuevo?" más seguro.

Por Anónimo (no verificado) , 29 Abril 2026

Introducción

git clone parece una operación pero en realidad compone varias. Entender los pasos ayuda al solucionar problemas con clones parciales, clones lentos o predeterminados sorprendentes.

Por Anónimo (no verificado) , 29 Abril 2026

Introducción

Git soporta dos tipos de tags: lightweight, que son solo refs apuntando a commits, y anotados, que son objetos Git completos con metadatos. Usa tags anotados para releases.

Por Anónimo (no verificado) , 29 Abril 2026

Introducción

Git mantiene varias refs "auxiliares" especiales en .git/ para registrar estado durante operaciones multi-paso. Conocerlas convierte recuperaciones aterradoras en líneas únicas.

ORIG_HEAD

ORIG_HEAD se establece cada vez que una operación "peligrosa" mueve HEAD mucho: merge, rebase, reset, am. Captura la punta previa para que puedas deshacer:

git merge feature
# decidir que fue un error
git reset --hard ORIG_HEAD

El mismo truco después de un mal rebase o reset:

Por Anónimo (no verificado) , 29 Abril 2026

Introducción

Git almacena objetos en dos formatos: sueltos (un archivo por objeto bajo .git/objects/xx/yyyy...) y empaquetados (muchos objetos en un solo archivo .pack con un compañero .idx). Los packs son mucho más eficientes en disco y en la red.

Por Anónimo (no verificado) , 29 Abril 2026

Introducción

Un commit Git referencia cero, uno o varios commits padres. El historial entero es un grafo dirigido acíclico (DAG) de estos enlaces de padres. Los branches y tags son simplemente etiquetas en nodos de este grafo.

Anatomía de un enlace de padre

git cat-file -p HEAD
# tree 9f1a...
# parent b2c3...
# parent d4e5...        (solo en merge commits)
# author Ada ...
# committer Ada ...

Un padre: historial lineal. Dos padres: un merge. Cero padres: un commit raíz. Tres o más: un merge octopus.