Git pull: descarga y fusión de co­n­te­ni­dos

El comando git pull descarga el contenido de un re­po­si­to­rio remoto y realiza au­to­má­ti­ca­me­n­te una fusión. Puede es­pe­ci­fi­car el comando a través de varios ar­gu­me­n­tos.

Git permite que tú y los miembros de tu equipo co­la­bo­réis en un proyecto si­mu­l­tá­nea­me­n­te. Esto es posible gracias a los di­fe­re­n­tes re­po­si­to­rios en los que los de­sa­rro­lla­do­res pueden trabajar de forma autónoma antes de que los cambios útiles e im­po­r­ta­n­tes se integren en el proyecto general. Sin embargo, para que este principio dé re­su­l­ta­dos óptimos, es im­po­r­ta­n­te que la base de cada depósito local sea idéntica. Los cambios solo se pueden integrar si el punto de partida es el mismo. Por lo tanto, una he­rra­mie­n­ta im­po­r­ta­n­te para trabajar con el sistema de control de versiones es el comando de Git git pull.

Con git pull, descargas el contenido de un re­po­si­to­rio remoto y ac­tua­li­zas el re­po­si­to­rio local. Esto garantiza que puedas trabajar partiendo del estado actual. Una vez has terminado de trabajar en tu re­po­si­to­rio local, puedes subir los cambios e in­no­va­cio­nes al re­po­si­to­rio remoto uti­li­za­n­do el comando git push. Trabajar con git pull y push es es­pe­cia­l­me­n­te im­po­r­ta­n­te cuando varios usuarios están co­la­bo­ra­n­do en un proyecto al mismo tiempo y necesitas tener acceso constante al último estado. Git pull hace las veces de ac­tua­li­za­ción.

La sintaxis habitual de git pull también se puede encontrar en nuestro práctico resumen de Git de­s­ca­r­ga­ble en PDF. El comando, con la opción adicional sobre el re­po­si­to­rio remoto que se va a utilizar, se ve así:

El fu­n­cio­na­mie­n­to de git pull se explica mejor con otros dos comandos de Git, que bá­si­ca­me­n­te se ejecutan uno tras otro. En primer lugar, al igual que sucede con git fetch, es­pe­ci­fi­cas un re­po­si­to­rio remoto y descargas su estado actual, in­clu­ye­n­do todo el contenido. Después, realizas un git merge, fu­sio­na­n­do la copia remota y la copia local. No­r­ma­l­me­n­te, tendrías que ejecutar los dos comandos "git fetch <re­po­si­to­rio_remoto>" y "git merge origin/ <rama_actual>" uno tras otro, pero git pull los combina y usándolo te ahorras un paso de trabajo.

Además de la versión estándar de git pull descrita an­te­rio­r­me­n­te, existen algunas variantes de este útil comando, que te pre­se­n­ta­mos a co­n­ti­nua­ción.

Puedes ampliar el git pull clásico para que descargue el contenido del re­po­si­to­rio remoto, pero sin que Git cree un nuevo commit con la unión de ambos re­po­si­to­rios. El comando tiene entonces el siguiente aspecto:

En esta variante, todo el contenido de un re­po­si­to­rio remoto se descarga mediante git pull, pero en lugar de un merge, la fusión se realiza con git rebase. Así se escribe el comando:

Esta opción ejecuta git pull normal, pero te da una lista exacta de los nuevos archivos. Así sabes en qué co­n­te­ni­dos puedes seguir tra­ba­ja­n­do.

Los comandos git pull y git fetch pueden co­n­fu­n­di­r­se, es­pe­cia­l­me­n­te al principio. Al fin y al cabo, su fu­n­cio­na­mie­n­to básico es similar, ya que ambos comandos descargan co­n­te­ni­dos de un re­po­si­to­rio remoto. Sin embargo, git fetch no modifica el re­po­si­to­rio local; hace que los archivos ne­ce­sa­rios estén di­s­po­ni­bles, pero mantiene el estado actual. Git pull, por otro lado, actualiza el re­po­si­to­rio local in­me­dia­ta­me­n­te. Aunque esto puede ahorrar tiempo, también puede generar problemas.

En el siguiente ejemplo práctico, te enseñamos cómo funciona git pull. Como el comando ejecuta dos pasos seguidos, el código es más corto y solo está compuesto de unas pocas líneas en total. En nuestro ejemplo, uti­li­za­mos el comando git checkout para cambiar a nuestro re­po­si­to­rio local, y en el segundo paso eje­cu­ta­mos git pull. El comando hace que se descargue el contenido de nuestro re­po­si­to­rio remoto y que Git active el git merge di­re­c­ta­me­n­te después, de modo que nuestro re­po­si­to­rio local se actualiza in­me­dia­ta­me­n­te. Así es como se ve en la práctica:

Para ase­gu­rar­se de que el historial sea lo más claro posible, muchos de­sa­rro­lla­do­res prefieren pre­s­ci­n­dir de git merge y recurrir a git rebase. En este caso, tus cambios aparecen antes de los de otros miembros del equipo. Dado que git pull en realidad también sirve para fusionar, el comando debe ampliarse añadiendo la me­n­cio­na­da opción "--rebase". En la práctica, esto se ve así: