Introducción

git fetch descarga nuevos objetos y actualiza las refs de seguimiento remoto sin cambiar tu árbol de trabajo. git pull hace fetch y luego integra el resultado en tu branch actual. Conocer la diferencia es uno de los mayores pasos de novato a usuario confiado de Git.

Fetching

git fetch                  # remoto predeterminado (normalmente origin)
git fetch origin
git fetch --all
git fetch --prune          # eliminar refs de branches eliminados en el servidor
git fetch origin main      # solo un branch

Después de un fetch, inspecciona qué cambió:

git log HEAD..origin/main --oneline
git diff HEAD origin/main

Pulling

git pull es atajo para fetch seguido de merge o rebase. Elige la estrategia:

git pull                          # usa la config pull.rebase
git pull --rebase
git pull --ff-only                # rechazar si no es fast-forward
git pull origin main

Configurando comportamiento predeterminado

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
git config --global fetch.prune true

Desde Git 2.27 un git pull sin argumentos advierte si no hay estrategia configurada.

Fetch vs pull, cuándo usar cuál

• Usa fetch cuando quieras mirar antes de integrar.
• Usa pull --ff-only cuando simplemente quieras ponerte al día en un branch compartido.
• Usa pull --rebase cuando trabajas en un topic branch que aún no has pusheado.
• Evita un pull simple en branches compartidos de larga vida; los merge commits se multiplican.

Inspeccionando upstream

git status
# On branch main
# Your branch is behind 'origin/main' by 3 commits, and can be fast-forwarded.

Este mensaje viene de comparar HEAD con la origin/main cacheada; ejecuta git fetch primero para hacerlo preciso.

Haciendo fetch de pull requests

La mayoría de los hosts de Git exponen los branches de pull o merge requests como refs especiales que puedes traer a tu clon para revisión. Para GitHub, añade un refspec:

git config --add remote.origin.fetch '+refs/pull/*/head:refs/remotes/origin/pr/*'
git fetch
git switch -c review/123 origin/pr/123

Para GitLab la ruta equivalente es refs/merge-requests/*/head. Con esto configurado, cada git fetch trae todos los PRs abiertos localmente, listos para inspección sin salir de tu terminal.

Errores comunes

Ejecutar git pull con cambios no commiteados y obtener un merge commit inesperado encima de trabajo sucio. Stashea o commitea primero. Olvidar que el conteo de "behind" de git status es solo tan fresco como el último fetch; si nadie ha hecho fetch en una semana, ese conteo miente. Usar git pull --rebase en un branch sobre el que otras personas han basado trabajo reescribe su base; rebase solo en branches privados. Y finalmente, nunca uses git fetch <refspec> con un refspec personalizado a menos que lo entiendas; un dos puntos accidental (main:main) sobrescribe tu main local.