git pull

El comando git pull se utiliza para obtener y descargar contenido de un repositorio remoto y actualizar inmediatamente el repositorio local para que coincida con ese contenido. La fusión de los cambios remotos en el repositorio local es una tarea común en los flujos de trabajo de colaboración basados en Git. El comando git pull es en realidad una combinación de otros dos comandos, git fetch seguido de git merge. En la primera etapa de funcionamiento git pull ejecutará un git fetch con alcance a la rama local a la que HEAD apunta. Una vez descargado el contenido, git pull entrará en un flujo de trabajo de fusión. Se creará un nuevo merge commit y se actualizará HEAD para que apunte al nuevo commit.

Uso de Git pull

El comando git pull ejecuta primero git fetch que descarga el contenido del repositorio remoto especificado. Luego se ejecuta un git merge para fusionar las refs de contenido remotas y las cabezas en un nuevo merge commit local. Para demostrar mejor el proceso de pull y merging consideremos el siguiente ejemplo. Supongamos que tenemos un repositorio con una rama maestra y un origen remoto.

En este escenario, git pull descargará todos los cambios desde el punto en el que la local y la maestra divergieron. En este ejemplo, ese punto es E. git pull obtendrá los commits remotos divergentes que son A-B-C. El proceso de pull creará entonces un nuevo commit local de fusión que contiene el contenido de los nuevos commits remotos divergentes.

En el diagrama anterior, podemos ver el nuevo commit H. Este commit es un nuevo commit de fusión que contiene el contenido de los commits remotos A-B-C y tiene un mensaje de registro combinado. Este ejemplo es una de las pocas estrategias de fusión git pull. Se puede pasar una opción --rebase a git pull para utilizar una estrategia de fusión rebase en lugar de una confirmación de fusión. El siguiente ejemplo demostrará cómo funciona un rebase pull. Supongamos que estamos en un punto de partida de nuestro primer diagrama, y hemos ejecutado git pull --rebase.

En este diagrama, ahora podemos ver que un rebase pull no crea el nuevo commit H. En su lugar, el rebase ha copiado los commits remotos A–B–C y ha reescrito los commits locales E–F–G para que aparezcan después de ellos en el historial de commits del origen/maestro local.

Opciones comunes

git pull <remote>

Obtener la copia remota especificada de la rama actual y fusionarla inmediatamente con la copia local. Esto es lo mismo que git fetch <remote> seguido de git merge origin/<current-branch>.

git pull --no-commit <remote>

Similar a la invocación por defecto, obtiene el contenido remoto pero no crea un nuevo merge commit.

git pull --rebase <remote>

Igual que el pull anterior En lugar de usar git merge para integrar la rama remota con la local, usa git rebase.

git pull --verbose

Da una salida verbosa durante un pull que muestra el contenido que se está descargando y los detalles de la fusión.

Discusión del pull de Git

Puedes pensar en git pull como la versión de Git de svn update. Es una forma sencilla de sincronizar tu repositorio local con los cambios del upstream. El siguiente diagrama explica cada paso del proceso de extracción.

Empiezas pensando que tu repositorio está sincronizado, pero entonces git fetch revela que la versión de origen de master ha progresado desde la última vez que lo revisaste. Entonces git merge integra inmediatamente el master remoto en el local.

Tracción y sincronización de Git

git pull es uno de los muchos comandos que reclaman la responsabilidad de «sincronizar» el contenido remoto. El comando git remote se utiliza para especificar sobre qué puntos finales remotos operarán los comandos de sincronización. El comando git push se utiliza para subir contenido a un repositorio remoto.

El comando git fetch puede confundirse con git pull. Ambos se utilizan para descargar contenido remoto. Se puede hacer una importante distinción de seguridad entre git pull y get fetchgit fetch puede considerarse la opción «segura» mientras que, git pull puede considerarse inseguro. git fetch descargará el contenido remoto y no alterará el estado del repositorio local. Alternativamente, git pull descargará el contenido remoto e inmediatamente intentará cambiar el estado local para que coincida con ese contenido. Esto puede causar involuntariamente que el repositorio local se encuentre en un estado conflictivo.

Tirar a través de Rebase

La opción --rebase se puede utilizar para asegurar una historia lineal evitando confirmaciones de fusión innecesarias. Muchos desarrolladores prefieren rebasar en lugar de fusionar, ya que es como decir: «Quiero poner mis cambios encima de lo que todo el mundo ha hecho.» En este sentido, usar git pull con el flag --rebase es aún más parecido a svn update que un git pull a secas.

De hecho, tirar con --rebase es un flujo de trabajo tan común que hay una opción de configuración dedicada para ello:

git config --global branch.autosetuprebase always

Después de ejecutar ese comando, todos los comandos git pull se integrarán a través de git rebase en lugar de git merge.

Ejemplos de Git Pull

Los siguientes ejemplos demuestran cómo utilizar git pull en escenarios comunes:

Comportamiento por defecto

git pull

Ejecutar la invocación por defecto de git pull será equivalente a git fetch origin HEAD y git merge HEAD donde HEAD es ref apuntando a la rama actual.

Git pull en remotas

git checkout new_feature
git pull <remote repo>

Este ejemplo primero realiza un checkout y cambia a la rama. A continuación, se ejecuta el git pull con ser pasado. Esto implícitamente bajará la rama newfeature de . Una vez completada la descarga iniciará un git merge.

Git pull rebase en lugar de merge

El siguiente ejemplo demuestra cómo sincronizar con la rama maestra del repositorio central utilizando un rebase:

git checkout master
git pull --rebase origin

Esto simplemente mueve tus cambios locales encima de lo que todos los demás ya han contribuido.