git pull

Compartir y actualizar

Descargar de otro repositorio o de una rama local e integrar

El comando 'git pull' descarga contenido de un repositorio remoto y lo integra enseguida en tu rama local. En esencia es 'git fetch' seguido de 'git merge' (o de 'git rebase' con la opción --rebase). Es la forma más habitual de sincronizar tu repositorio local con los cambios de los demás. Al ejecutar git pull, Git descarga primero todos los commits nuevos del remoto y después los integra en tu rama actual. Si tu rama solo va por detrás, hace fast-forward; si los dos lados tienen commits nuevos, el Git moderno se detiene y te pide elegir entre merge y rebase (--no-rebase / --rebase, o la opción pull.rebase). Si hay cambios en conflicto, Git se detiene y te pide resolverlos antes de completar el merge.

Sinopsis

git pull [--rebase | --no-rebase] [--ff-only | --ff | --no-ff] [--commit | --no-commit] [--autostash | --no-autostash] [-q | --quiet] [-v | --verbose] [--depth=<depth>] [--prune] [--tags | --no-tags] [--recurse-submodules[=yes|on-demand|no]] [<repository> [<refspec>...]]
[ ] opcional| o<arg> valor a sustituir... repetible--flag opción

Opciones

Haz clic en una opción para desplegarla

Principiante (7)

El nombre del remoto por defecto. Al clonar un repositorio, Git llama automáticamente 'origin' al remoto. Puedes hacer pull desde origin indicándolo o confiar en la configuración de seguimiento por defecto.

Cuando haga faltaIndica explícitamente el remoto y la rama; git pull a secas usa el upstream

Ejemplo

git pull origin main

Tras el fetch, hacer rebase de la rama actual sobre la rama upstream. Crea un historial lineal reproduciendo tus commits locales encima de los descargados, sin commits de merge.

RecomendadoReaplica encima tus commits sin subir y mantiene el historial lineal

Ejemplo

git pull --rebase origin main

Atajo de --rebase=false. Anula cualquier configuración que haga rebase por defecto y fuerza un merge en lugar de un rebase al integrar los cambios descargados. Crea un commit de merge si los historiales se han separado.

Cuando haga faltaFusiona explícitamente cuando las ramas divergieron o la configuración usa rebase por defecto

Ejemplo

git pull --no-rebase origin main

Actualizar solo si la rama local puede avanzar con fast-forward (sin commits locales por delante del remoto). Falla si los historiales se han separado, lo que evita merges accidentales y te obliga a decidir cómo integrar.

RecomendadoNunca crea merges inesperados; se detiene para que elijas cuando las ramas divergen

Ejemplo

git pull --ff-only origin main

Modo detallado. Muestra información detallada del fetch y del merge, incluidas las referencias que se actualizan y las estadísticas de transferencia de objetos.

Cuando haga faltaPara depurar lo que hacen fetch y merge

Ejemplo

git pull -v origin main

Silenciar la salida durante el fetch y el merge. Solo se muestran los errores. Útil en scripts que deben funcionar en silencio.

Cuando haga faltaPara scripts; oculta el progreso y la salida del merge

Ejemplo

git pull -q origin main

Guardar automáticamente las modificaciones locales antes del pull y volver a aplicarlas al terminar (funciona con pulls por merge y por rebase; si al reaplicarlas hay conflictos, tus cambios quedan a salvo en el stash). Perfecto cuando tienes cambios sin commit pero necesitas sincronizarte.

Cuando haga faltaCómodo con trabajo sin commit; si hay conflicto al volver a aplicarlo, queda en el stash

Ejemplo

git pull --rebase --autostash origin main

Intermedio (6)

Hacer el merge pero detenerse antes de crear el commit de merge. Te permite revisar, y si quieres modificar, el resultado antes del commit.

Cuando haga faltaSe detiene antes del commit de merge para que puedas revisar el resultado

Ejemplo

git pull --no-commit origin main

Antes del fetch, quitar las referencias de seguimiento remoto que ya no existen en el remoto. Ayuda a mantener tu repositorio local libre de ramas obsoletas. Solo poda cuando se usan los refspecs configurados del remoto: 'git pull --prune origin main' no poda nada.

Cuando haga faltaLimpia referencias de seguimiento remoto obsoletas; no hace nada con un refspec explícito

Ejemplo

git pull --prune

Descargar todas las etiquetas del remoto además de lo que se descargaría normalmente. Útil para sincronizar las etiquetas de release.

Cuando haga faltaTambién trae etiquetas fuera del historial que se trae; casi nunca hace falta

Ejemplo

git pull --tags origin main

Desactivar el seguimiento automático de etiquetas: por defecto también se descargan las etiquetas que apuntan a los commits descargados. Anula la opción remote.<name>.tagOpt. Útil cuando solo quieres actualizar ramas.

Cuando haga faltaOmite el seguimiento automático de etiquetas para actualizar solo ramas

Ejemplo

git pull --no-tags origin main

Limitar la descarga al número de commits indicado desde la punta del historial de cada rama remota. Crea o amplía un clon superficial. Útil en repositorios grandes.

Cuando haga faltaMantiene superficial un clon superficial (CI); los comandos basados en el historial ven menos

Ejemplo

git pull --depth=1 origin main

Descargar de todos los remotos. En lugar de un solo remoto, descarga de todos los configurados antes del merge.

Cuando haga faltaTrae de todos los remotos pero solo fusiona el upstream actual

Ejemplo

git pull --all

Avanzado (4)

Controlar si los submódulos se descargan y actualizan de forma recursiva. Valores: 'yes' (siempre), 'on-demand' (cuando el superproyecto actualiza la referencia del submódulo), 'no' (nunca).

Cuando haga faltaSolo en repositorios con submódulos, para mantenerlos sincronizados

Ejemplo

git pull --recurse-submodules=on-demand origin main

Convertir un repositorio superficial en uno completo descargando todo el historial que falta. Solo es válido al hacer pull en un clon superficial.

Cuando haga faltaConvierte un clon superficial en completo cuando necesitas todo el historial

Ejemplo

git pull --unshallow origin main

Usar la estrategia de merge indicada. Estrategias habituales: ort (la predeterminada), resolve, octopus, ours, subtree. recursive se sigue aceptando, pero desde Git 2.50 solo es un sinónimo de ort.

Cuando haga faltaCasi nunca hace falta; la estrategia ort predeterminada sirve para casi todos los pull

Ejemplo

git pull -s ort origin main

Permitir el merge de historiales sin ningún ancestro común. Necesario al unir dos repositorios creados por separado.

No recomendadoSolo para unir repositorios separados a propósito; si no, oculta un error

Ejemplo

git pull --allow-unrelated-histories origin main

Elegir la opción adecuada

Estrategia de pull: merge o rebase

La decisión clave que afecta a tu historial de commits

ComandoCrea commit de mergeEstilo de historialIdeal para
git pullDepende de la configuración (falla si divergen y no está configurado)Lo fijan pull.rebase / pull.ffFast-forward si solo vas por detrás
git pull --rebaseNoLinealRamas de funcionalidad, historial limpio
git pull --no-rebaseSí (si divergen)Conserva las ramasAnular la configuración de rebase y forzar merge
git pull --ff-onlyNoLineal (falla si divergen)Asegurarse de no hacer merges accidentales

Opciones de seguridad y control

Opciones para evitar errores y mantener el control

ComandoEvitaComportamientoCuándo usarla
--ff-onlyMerges inesperadosFalla si no puede hacer fast-forwardCI/CD, ramas protegidas
--no-commitCommit automáticoIntegra pero se detiene antes del commitRevisar el merge antes del commit
--autostashErrores por directorio de trabajo con cambiosStash → pull → popSincronización rápida con trabajo sin commit
--dry-runCualquier cambioMuestra lo que descargaría fetch; sin mergeVer de antemano las referencias entrantes

Qué se descarga

Controlar qué referencias e historial se descargan

ComandoTrae etiquetasDescarga todo el historialCaso de uso
git pullAuto (etiquetas seguidas)SíFlujo normal
--tagsTodas las etiquetasSíSincronizar versiones publicadas
--no-tagsNoSíAhorrar ancho de banda, sincronizar solo una rama
--depth=NAuto (etiquetas seguidas)Solo los N últimos commitsRepositorios grandes, builds de CI
--unshallowAuto (etiquetas seguidas)Convierte un clon superficial en completoNecesitas todo el historial tras un clon superficial

Gestión de remotos y ramas

Opciones para manejar varios remotos y referencias obsoletas

ComandoAlcanceLimpiaEscenario
git pull origin mainUn solo remoto/ramaNoPull normal desde origin
--allTodos los remotosNoSincronizar desde origin + upstream
--pruneUn solo remotoRamas borradasQuitar referencias de seguimiento obsoletas

Casos avanzados

Opciones para situaciones complejas o poco habituales

ComandoResuelveNivel de riesgoCaso típico
--allow-unrelated-historiesSin ancestro comúnMediaUnir dos repositorios separados
-s <strategy>Necesidades especiales de merge (no evita conflictos)BajoForzar un algoritmo de merge concreto
--recurse-submodulesSubmódulos desactualizadosBajoProyectos con submódulos de git

Ejemplos de flujos de trabajo

1
git status

Comprobar si hay cambios sin commit que puedan chocar

2
git stash

Guardar con stash el trabajo sin commit si hace falta (o usar --autostash)

3
git pull --rebase origin main

Hacer pull con rebase para mantener limpio el historial

4
git stash pop

Recuperar el trabajo guardado si lo guardaste antes

1
git checkout feature-branch

Cambiarse a tu rama de funcionalidad

2
git pull --no-rebase origin main

Integrar el último main en tu rama de funcionalidad (de forma explícita, porque las ramas se han separado)

3
git push origin feature-branch

Subir la rama de funcionalidad actualizada

1
git fetch origin

Descargar los cambios remotos sin tocar el directorio de trabajo

2
git log HEAD..origin/main

Ver qué commits vas a traer

3
git diff HEAD...origin/main

Revisar los cambios hechos en el remoto

4
git pull origin main

Hacer pull cuando estés conforme con los cambios

1
git pull --no-rebase origin main

Intentar un pull con merge (puede generar conflictos)

2
git status

Ver qué archivos tienen conflictos (marcados como 'both modified')

3
(edit conflicted files)

Abrir los archivos y resolver las marcas de conflicto (<<<<<<<, =======, >>>>>>>)

4
git add <resolved-files>

Preparar los archivos resueltos

5
git commit

Completar el merge con un commit

1
git pull --rebase --autostash origin main

Guardar automáticamente los cambios, hacer pull y volver a aplicarlos

Solución de problemas

Your local changes would be overwritten by merge

Causa: Tienes cambios sin commit en archivos que el pull modificaría

Haz commit de tus cambios primero (git add . && git commit), guárdalos con stash (git stash) o usa git pull --rebase --autostash

git stash && git pull && git stash pop

Refusing to merge unrelated histories

Causa: Los repositorios remoto y local no tienen ningún ancestro común (p. ej., al hacer pull en un repositorio recién inicializado)

Permitir el merge de historiales sin relación, algo habitual al añadir un remoto a un repositorio local existente

git pull --allow-unrelated-histories origin main

Conflicto de merge en uno o varios archivos

Causa: Tanto tú como el remoto cambiasteis las mismas líneas de un archivo

Abre los archivos en conflicto, busca las marcas (<<<<<<<, =======, >>>>>>>), edítalos para resolver y luego git add y git commit. O cancela con git merge --abort

git add <resolved-file> && git commit

Not possible to fast-forward, aborting

Causa: Usaste --ff-only (o pull.ff=only está configurado), pero tu rama local se ha separado del remoto

Usa rebase en su lugar (git pull --rebase) o permite un commit de merge (git pull --no-rebase)

git pull --rebase origin main

Cannot pull with rebase: You have unstaged changes

Causa: Un pull con rebase necesita un árbol de trabajo limpio, y tienes modificaciones sin commit

Haz commit o stash de tus cambios, o usa autostash para gestionarlos automáticamente

git pull --rebase --autostash

No tracking information for the current branch

Causa: Tu rama no está configurada para seguir a una rama remota

Fija la rama upstream de forma explícita o indica el remoto y la rama en el comando pull

git branch --set-upstream-to=origin/main main

'origin' does not appear to be a git repository

Causa: No hay ningún remoto llamado 'origin' configurado

Revisa tus remotos con git remote -v y añade origin o usa el nombre de remoto correcto

git remote add origin <url>

You have divergent branches and need to specify how to reconcile them

Causa: Los dos lados tienen commits nuevos y no está configurado ni pull.rebase ni pull.ff, así que el Git moderno se niega a adivinar (las versiones 2.27+ anteriores solo avisaban)

Indica merge (--no-rebase) o rebase (--rebase), o configura un valor por defecto con git config pull.rebase

git config --global pull.rebase true

Consejos y trampas

Buenas prácticas

  • ✓Revisa siempre git status antes del pull para evitar conflictos con cambios sin commit
  • ✓Usa git pull --rebase para mantener un historial limpio y lineal en las ramas de funcionalidad
  • ✓Configura pull.rebase=true de forma global si prefieres rebase por defecto: git config --global pull.rebase true
  • ✓Haz primero git fetch cuando quieras revisar los cambios antes de integrarlos
  • ✓Usa --ff-only cuando quieras asegurarte de no crear commits de merge sin querer
  • ✓Configura el seguimiento con git push -u en el primer push para simplificar los pulls futuros
  • ✓Usa --autostash cuando tengas cambios sin commit pero necesites hacer pull rápido
  • ✓Haz pull de main/master a menudo para evitar merges grandes y complicados más adelante
  • ✓Resuelve los conflictos en el momento: nunca dejes tu repositorio en estado de conflicto
  • ✓Usa git pull --prune para limpiar las ramas de seguimiento remoto obsoletas
  • ✓Plantéate usar git fetch + git merge para tener más control sobre la integración
  • ✓Comprueba siempre que estás en la rama correcta antes del pull para no mezclar cambios

Errores comunes

  • ✗Hacer pull con cambios sin commit: puede provocar conflictos o fallar por completo. Haz commit o stash de tus cambios antes, o usa --autostash para gestionarlo automáticamente.
  • ✗No entender pull frente a fetch: 'git pull' integra automáticamente, lo que puede sorprender. Haz primero 'git fetch' si quieres revisar los cambios antes de integrarlos.
  • ✗Usar merge cuando rebase sería más limpio: en las ramas de funcionalidad, 'git pull --rebase' crea un historial lineal más limpio, sin commits de merge innecesarios.
  • ✗Ignorar los conflictos de merge: tras un pull con conflictos, tienes que resolverlos y hacer commit. Nunca dejes tu repositorio en estado de conflicto.
  • ✗Hacer pull en la rama equivocada: comprueba siempre tu rama actual con 'git status' antes del pull. Traer cambios a main cuando querías hacerlo en una rama de funcionalidad puede dar problemas.

Preguntas frecuentes

A:

git fetch solo descarga los commits nuevos del remoto sin modificar tu directorio de trabajo ni tus ramas locales. git pull hace fetch Y además integra automáticamente (con merge o rebase) esos cambios en tu rama actual. Usa fetch cuando quieras revisar los cambios antes de integrarlos.

A:

Usa --rebase cuando quieras un historial limpio y lineal (sobre todo en ramas de funcionalidad). Reproduce tus commits locales encima de los descargados en lugar de crear un commit de merge. Usa el pull normal (merge) cuando quieras conservar exactamente la historia de cuándo se hicieron los cambios.

A:

El fast-forward ocurre cuando tu rama local no tiene commits nuevos que el remoto no tenga. Git simplemente avanza el puntero de tu rama hasta el remoto, sin necesidad de un commit de merge. Si tienes commits locales, Git debe crear un commit de merge o hacer rebase; y salvo que pases --rebase/--no-rebase o configures pull.rebase, el Git moderno se detiene con «Need to specify how to reconcile divergent branches».

A:

Usa git pull --rebase para reproducir tus commits locales encima de los remotos y obtener un historial lineal. O usa git pull --ff-only, que solo funciona si es posible un fast-forward (falla si tienes commits locales por delante).

A:

Depende. Con un pull por merge, Git lo permite si los commits que llegan no tocan los archivos que modificaste; si no, se niega con «Your local changes ... would be overwritten by merge». Con --rebase, cualquier cambio sin commit bloquea el pull. Lo recomendable: haz commit antes o usa git pull --rebase --autostash para guardar y recuperar tus cambios automáticamente.

A:

Git pausa el merge y marca los archivos en conflicto. Abre cada uno, busca las marcas de conflicto (<<<<<<<, =======, >>>>>>>), edítalo para resolverlo y luego haz git add del archivo y git commit para completar el merge. Usa git merge --abort para cancelar (o, con git pull --rebase, git rebase --continue / git rebase --abort).

A:

Justo después del pull, ejecuta git reset --hard ORIG_HEAD: Git guarda tu punta anterior en ORIG_HEAD en los merges, fast-forwards y rebases. No uses HEAD~1: un fast-forward puede haber traído varios commits. --hard también descarta los cambios sin commit. Si ORIG_HEAD se ha movido desde entonces, encuentra la punta antigua con git reflog.

A:

Normalmente significa que haces pull de la rama o el remoto equivocados. Revisa: git branch -vv para ver la información de seguimiento, git remote -v para comprobar los remotos, y git fetch --all seguido de git log origin/main para ver los commits remotos.

A:

git pull origin main indica explícitamente el remoto y la rama de los que traer cambios. git pull (sin argumentos) usa la rama de seguimiento configurada para tu rama actual. Si no hay seguimiento configurado, aparece un error que te pide indicarlos.

A:

De forma global: git config --global pull.rebase true (para rebase) o git config --global pull.rebase false (para merge). También puedes fijarlo por repositorio sin --global, o por rama con git config branch.<name>.rebase true.