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:

git fetch origin main
git merge origin/main             # o git rebase origin/main

Configuración

git config --global pull.rebase false   # merge (predeterminado clásico)
git config --global pull.rebase true    # rebase
git config --global pull.ff only        # solo fast-forward, abortar de lo contrario

Desde Git 2.27, un git pull simple sin configuración imprime una advertencia. Elige una estrategia explícitamente.

Solo fast-forward

--ff-only es el pull más seguro: tiene éxito solo si tu branch está estrictamente atrás. Sin merge commit, sin rebase, sin sorpresas.

git pull --ff-only

Combina con autostash para evitar bloqueadores del árbol de trabajo:

git pull --ff-only --autostash

Pull con rebase

git pull --rebase
git pull --rebase=merges          # preservar estructura de merge

--rebase=merges es útil para branches que contienen merge commits que quieres mantener.

Pull con autostash

git config --global rebase.autoStash true
git config --global merge.autoStash true

Con estos activados, los árboles sucios se stashean antes de la integración y se reaplican después, transparentemente.

Pull multi-branch

git pull origin main feature        # descarga ambos, mergea octopus en HEAD

Esto rara vez es lo que quieres; prefiere operaciones separadas.

Pull vs fetch + integrar explícito

Muchos usuarios experimentados prefieren nunca usar git pull. Ejecutan git fetch primero, inspeccionan git log HEAD..@{u} y luego eligen merge o rebase deliberadamente. Esto es especialmente valioso al integrar branches divergentes de larga duración.

Políticas de pull para equipos

Los equipos saludables eligen una política única de pull y la configuran a nivel organización. Dos elecciones comunes:

# Equipo de historial lineal: rebase al pull, merge solo vía PR
git config --global pull.rebase true
git config --global rebase.autoStash true

# Equipo amigo de merges: nunca rebasear, siempre fast-forward main
git config --global pull.rebase false
git config --global pull.ff only

La peor configuración es la ausente: el git pull de cada desarrollador se comporta diferente, produciendo historiales inconsistentes. Documenta la política en el CONTRIBUTING.md de tu repo y proporciona un fragmento de configuración de una línea que los nuevos contribuyentes puedan copiar.

Errores comunes

Ejecutar git pull con cambios no commiteados y obtener un merge commit inesperado encima de trabajo sucio. O bien stashea, commitea, o configura autoStash. Hacer pull con rebase en un branch en el que otros han basado trabajo; reescribes su base. Rebasea solo en branches privados. Configurar pull.rebase globalmente sin darte cuenta de que también afecta a main; muchos equipos configuran pull.ff only globalmente y sobrescriben por branch. Finalmente, usar git pull en CI; CI rara vez necesita integración, solo el último commit. Usa git fetch y un checkout explícito de origin/main para mantener CI determinista.