git pull

Qué hace git pull

git pull descarga nuevos commits de un repositorio remoto y los integra inmediatamente en tu rama local actual. Es el comando que ejecutas para sincronizar tu trabajo con lo que tus compañeros han subido.

Internamente, git pull es un atajo conveniente para dos comandos ejecutados uno tras otro:

git fetch <remote>          # download the new commits
git merge <remote>/<branch> # integrate them into the current branch

Así que git pull equivale a git fetch seguido de git merge. Entender esa separación es la clave para comprender el comando completo: fetch actualiza tus ramas de seguimiento remotas sin tocar tu trabajo, y merge (o rebase, véase más abajo) reproduce la nueva historia en tu rama.

Cuándo usarlo

git pull forma parte del flujo de trabajo de "sincronización" de Git, junto con git push, git fetch y git remote. Úsalo siempre que quieras que tu rama local refleje el estado más reciente del remoto, por ejemplo:

• Antes de comenzar un nuevo trabajo, para que construyas sobre el código más actualizado.
• Antes de ejecutar git push, para que tu push avance en modo fast-forward en lugar de ser rechazado como "non-fast-forward".
• Para recoger los commits de un compañero en una rama compartida.

git fetch y git pull descargan contenido remoto, pero difieren en un aspecto importante: git fetch solo actualiza tus ramas de seguimiento remotas y deja tu copia de trabajo intacta, mientras que git pull también fusiona esos cambios en tu rama actual. Si quieres inspeccionar los commits entrantes antes de integrarlos, haz fetch primero y fusiona tú mismo.

Cómo funciona la fusión durante un pull

Supongamos que tu rama local y el remoto comparten la historia hasta el commit E y luego divergen. El remoto ha ganado los commits A, B y C que tú no tienes. Al ejecutar git pull se obtienen esos commits.

Git crea entonces un nuevo commit de fusión, H, que une tu trabajo local con los commits obtenidos A, B y C, combinando ambas líneas de historia.

Si tu rama local no ha divergido (no tienes nuevos commits locales), Git simplemente mueve el puntero de tu rama hacia adelante hasta los nuevos commits. Esto se llama fast-forward y no produce ningún commit de fusión.

Con la opción --rebase, Git reproduce tus commits locales sobre los commits obtenidos en lugar de crear un commit de fusión, manteniendo la historia lineal.

Opciones comunes

Ejemplos

Pull desde la rama upstream

Invocar git pull sin argumentos obtiene y fusiona los cambios de la rama upstream configurada para la rama actual:

git pull

Para que esto funcione, la rama actual debe tener configurado un upstream (Git lo almacena después del primer git push -u o git branch --set-upstream-to).

Pull desde un remoto y rama específicos

Puedes nombrar el remoto y la rama de forma explícita:

git pull <remote> <branch>

Esto obtiene y fusiona los cambios de la rama especificada del remoto indicado. Por ejemplo, para hacer pull de la rama develop desde el remoto origin:

git pull origin develop

Pull con rebase

git pull --rebase

En lugar de fusionar, esto reproduce tus commits locales sobre los commits obtenidos. El resultado es una historia lineal sin commit de fusión, que muchos equipos prefieren para las ramas de funcionalidades. Para que esto sea el comportamiento predeterminado de una rama, configura git config pull.rebase true. Consulta git rebase para conocer las ventajas e inconvenientes.

Pull sin confirmar la fusión

git pull --no-commit

Esto obtiene y fusiona, pero se detiene justo antes de crear el commit de fusión, dejando el resultado preparado para que puedas revisarlo (y modificarlo) antes de confirmar con git commit.

Resolución de conflictos tras un pull

Si los commits remotos modificaron las mismas líneas que tú cambiaste localmente, la fusión no puede completarse automáticamente y Git reporta un conflicto:

Auto-merging app.js
CONFLICT (content): Merge conflict in app.js
Automatic merge failed; fix conflicts and then commit the result.

Para resolverlo, abre cada archivo en conflicto, edítalo para conservar el contenido correcto (eliminando los marcadores <<<<<<<, ======= y >>>>>>>), luego prepara y confirma los cambios:

git add app.js
git commit

Si prefieres no lidiar con el conflicto en este momento, git merge --abort devuelve tu rama al estado anterior al pull.

Práctica