Con la autenticación resuelta, el canal está abierto. Ana ha subido gestor-tareas al servidor del equipo —el mecanismo exacto del envío lo desmenuzaremos en la lección siguiente— y por primera vez en el curso hay objetos Git en una máquina distinta de la suya.

Ahora toca el otro sentido del viaje: recibir. Y aquí nos topamos con la confusión más extendida de todo Git, la que produce más sustos y más preguntas en foros: la diferencia entre git fetch y git pull.

La confusión es comprensible, porque los nombres no ayudan: fetch es "buscar" y pull es "tirar de algo". Suenan a sinónimos. No lo son en absoluto:

• git fetch descarga y actualiza tus referencias remotas. No toca ni un solo fichero de tu directorio de trabajo. Es una operación completamente inofensiva.
• git pull hace un fetch y, acto seguido, integra lo descargado en tu rama actual. Sí modifica tus ficheros y puede provocar conflictos.

Entender bien esa diferencia cambia por completo la relación que tienes con los remotos: pasas de "ejecuto pull y a ver qué pasa" a "miro qué hay, decido y luego integro". En esta lección la desmenuzamos, y Carla clona por fin el proyecto y se pone al día.

1. El punto de partida: el proyecto ya está en el servidor
2. git fetch: qué hace exactamente
3. El antes y el después de un fetch
4. FETCH_HEAD: la referencia que casi nadie conoce
5. Inspeccionar lo traído antes de integrarlo
6. Integrar a mano: merge sobre origin/main
7. git pull = fetch + integración
8. Los modos de git pull
9. Limpiar referencias obsoletas: --prune
10. Carla se incorpora y se pone al día
11. Cuando las historias divergen

Situación actual del equipo:

Ana ha publicado. Bruno ya ha actualizado su clon. Carla todavía no tiene nada.

Para reproducirlo en tu máquina, montamos el escenario completo con lo aprendido en las lecciones anteriores:

Cuatro commits en el servidor y dos repositorios sincronizados. A partir de aquí trabajamos.

Bruno se pone a trabajar por la mañana. Ana lleva desde ayer añadiendo cosas y ha enviado dos commits nuevos. Bruno no lo sabe: recuerda de la lección 04-01 que su origin/main es una foto con fecha de ayer y que nadie le va a avisar.

Simulemos el trabajo de Ana:

Y ahora Bruno:

La línea que importa es la última, y conviene leerla con cuidado:

Lo que se ha actualizado es origin/main, no main. Esa flecha lo dice literalmente: la rama main del servidor se ha guardado en tu referencia origin/main. Es el refspec de la lección 04-02 en acción.

1. Se conecta al remoto y le pregunta qué referencias tiene.
2. Descarga los objetos que a ti te faltan (commits, árboles, blobs) y los guarda en .git/objects/.
3. Actualiza las referencias remotas en .git/refs/remotes/origin/ según el refspec configurado.

1. No toca tu directorio de trabajo. Ni un fichero. Ni uno.
2. No mueve ninguna de tus ramas locales. Tu main sigue exactamente donde estaba.
3. No puede provocar conflictos. No hay nada que combinar: solo se añaden objetos y se mueven punteros de referencias que no son tuyas.

La demostración es inmediata:

"nothing to commit, working tree clean": el fetch no ha cambiado nada en el disco de trabajo. Lo único nuevo es que ahora Git sabe que hay dos commits esperando, porque puede comparar main con origin/main. De dónde sale exactamente ese mensaje y cómo se calcula es el tema de la lección 04-06.

Dos referencias, dos commits distintos. Este es el estado normal después de un fetch, y no tiene nada de anómalo.

La consecuencia práctica más importante de toda la lección: git fetch es absolutamente seguro. No puede romper nada, no puede perder trabajo, no puede provocar un conflicto y no puede dejarte a medias de nada. Puedes ejecutarlo cuando quieras, incluso con cambios sin confirmar en tu directorio de trabajo. La única consecuencia es que estarás mejor informado.

Y uno que no descarga nada en absoluto y es utilísimo para diagnosticar:

Pregunta al servidor qué referencias tiene y a qué commits apuntan, sin descargar un solo objeto. Es la forma más barata de comprobar si hay novedades o si el remoto responde.

Visto en el grafo, que es donde mejor se entiende:

Fíjate en los dos detalles que resumen toda la lección:

1. Han aparecido dos commits nuevos (9e2f4a7 y b4d7e93) en la base de datos de objetos de Bruno. Están ahí, completos, consultables sin conexión.
2. main no se ha movido. Sigue en c2a8f1e, exactamente donde estaba. Solo origin/main ha avanzado.

Y como los objetos ya están en su disco, Bruno puede examinarlos con todo lo que aprendió en el módulo 2, sin red y sin haber integrado nada:

Esto es una de las grandes ventajas del modelo distribuido: descargar y decidir son dos actos separados. Puedes traerte el trabajo de todo el equipo en el tren, con conexión intermitente, y estudiarlo tranquilamente después.

Cada git fetch escribe un fichero en la raíz de .git/:

FETCH_HEAD registra qué se trajo en la última operación de descarga. Tiene tres columnas:

Ese not-for-merge es la clave: marca las ramas que se han traído por el refspec pero que no son la que integrarías. Solo la rama de seguimiento de tu rama actual queda sin la marca.

Se puede usar como cualquier referencia:

Primero: es el mecanismo interno de git pull. Cuando ejecutas git pull, Git hace un fetch y luego un git merge FETCH_HEAD. Saberlo desmitifica por completo el comando: no hay magia, hay dos pasos encadenados.

Segundo: permite traer de una URL sin registrar ningún remoto. Este caso ocurre más de lo que parece, por ejemplo al revisar el trabajo de alguien externo:

Es efímero: cada fetch sobrescribe FETCH_HEAD. Si vas a necesitar ese commit más adelante, crea una rama o una referencia con nombre; si no, el recolector de basura acabará llevándoselo.

Aquí está el hábito profesional que distingue a quien entiende Git de quien lo padece: entre el fetch y la integración hay un hueco, y ese hueco es para mirar.

Bruno ya tiene los commits de Ana en su disco. Antes de mezclarlos con su trabajo, los estudia.

Recuerda del módulo 2 la semántica del rango a..b: "commits alcanzables desde b pero no desde a". Es decir: lo que tiene el servidor y yo no.

Vacío: Bruno no ha confirmado nada desde su última sincronización. Si hubiera commits aquí y en el rango anterior, las historias habrían divergido; ese caso lo tratamos en el apartado 11.

Un vistazo rápido a la superficie del cambio. Y si quieres el detalle:

El unified diff de la lección 02-05, sin ninguna diferencia: origin/main es una referencia como cualquier otra.

La opción --all incluye todas las referencias, también las remotas. Es la vista que hay que tener a mano en cuanto trabajas con un remoto.

Este es el flujo recomendado: fetch → mirar → decidir → integrar. Cuesta veinte segundos y evita el desconcierto de un pull que de repente ha modificado quince ficheros que no esperabas.

Bruno ya ha visto lo que hay y le parece bien. Ahora sí, integra:

Y esto es exactamente el git merge del módulo 3. Nada nuevo. Como Bruno no tenía commits propios, main estaba por detrás sin haber divergido, y Git ha aplicado un fast-forward: mover el puntero hacia delante. El mismo caso que estudiamos con las ramas locales.

Ahora las tres referencias coinciden: main, origin/main y la rama del servidor.

Este es el punto en el que conviene detenerse un momento, porque resume la promesa del final del módulo 3:

Integrar el trabajo de otra persona es exactamente el mismo git merge que has usado con tus propias ramas. Fast-forward si no has divergido, fusión a tres bandas si sí, con la posibilidad de conflictos que ya sabes resolver. Los remotos no cambian nada de eso: solo cambian de dónde vienen los commits.

Y con eso, git pull deja de tener misterio:

git pull es un atajo de git fetch seguido de una integración de la rama de seguimiento en tu rama actual.

Es literalmente así. Estos dos bloques hacen lo mismo:

Las dos mitades tienen naturalezas opuestas, y por eso conviene verlas separadas:

Usa git fetch cuando:

• Quieres saber qué hay de nuevo sin comprometerte a nada.
• Tienes cambios sin confirmar y no quieres que nada se mueva.
• Estás en mitad de algo delicado.
• Quieres revisar el trabajo de otra persona antes de mezclarlo.
• Vas a quedarte sin conexión y quieres tenerlo todo descargado.

Usa git pull cuando:

• Empiezas la jornada y solo quieres ponerte al día.
• Estás seguro de que no has divergido.
• Trabajas en una rama que solo tocas tú.

Recomendación honesta: si estás empezando, acostúmbrate a git fetch + mirar + integrar. Es un paso más y quince segundos, pero te da un modelo mental correcto y evita el 90 % de los sustos. Cuando ya entiendas perfectamente qué va a pasar, git pull es un atajo legítimo.

La parte de fetch de pull siempre es igual. Lo que cambia es cómo integra, y ahí hay tres comportamientos posibles. Este es el motivo por el que en la lección 01-06 configuramos:

Integra únicamente si se puede resolver con un fast-forward, es decir, si tu rama no tiene ningún commit propio. Si has divergido, se detiene sin hacer nada:

Esto no es un error: es la configuración funcionando. Git te está diciendo "aquí hay una decisión que tomar y no la voy a tomar yo". Es exactamente lo que queríamos al fijar pull.ff only en la configuración inicial: nunca crear commits de fusión por sorpresa.

Es el modo más conservador y el mejor mientras aprendes.

Integra con git merge. Si puede hacer fast-forward, lo hace; si has divergido, crea un commit de fusión con dos padres.

Este era el comportamiento por defecto histórico de Git, y es la razón por la que tantos repositorios están llenos de commits titulados Merge branch 'main' of https://…. Cada uno de ellos es alguien que ejecutó git pull habiendo divergido, sin enterarse de que estaba creando un commit.

Ese ruido en el historial es, precisamente, uno de los problemas que abordará el módulo 5.

En lugar de fusionar, reaplica tus commits locales encima de lo que ha traído del servidor, produciendo un historial lineal sin commits de fusión.

Es una técnica potente y muy usada, pero reescribe tus commits locales —les cambia el hash— y tiene reglas importantes sobre cuándo se puede y cuándo no. Merece una lección entera, y la tiene: lección 05-01: Rebase. Hasta entonces, quédate solo con que la opción existe y con lo que hace en una frase.

Y la configuración correspondiente, que ya conoces de la lección 01-06:

También se puede afinar por rama:

Si tienes modificaciones sin confirmar y la integración necesita tocar esos mismos ficheros, Git se niega:

Y hace bien: está protegiendo trabajo que solo existe en tu disco. Las opciones son confirmar, o guardar los cambios temporalmente con git stash (que es el tema de la lección 05-04).

Nótese que un git fetch en esa misma situación habría funcionado sin problema, porque no toca el directorio de trabajo. Una razón más para preferirlo.

Con el tiempo aparece un problema menor pero molesto. El equipo integra la rama funcionalidad/contador-tareas y la borra del servidor. Pero en el repositorio de Bruno, la referencia origin/funcionalidad/contador-tareas sigue ahí para siempre.

¿Por qué? Porque el refspec por defecto solo dice qué traer, no qué borrar. Un fetch normal nunca elimina referencias remotas.

Dos referencias fantasma. Y git remote show origin las delata:

Ese stale es exactamente lo que vimos en la lección 04-02: "tú tienes esta referencia, pero en el servidor ya no está."

Y para ver qué se borraría sin borrar nada:

Como esto hay que hacerlo siempre y no tiene ningún inconveniente, lo razonable es configurarlo de una vez:

A partir de ahora, todos tus fetch y pull limpian las referencias muertas. Es uno de los ajustes que más agradece un repositorio de equipo con rotación de ramas.

Y si además quieres limpiar etiquetas borradas en el servidor:

Con esta última hay que ir con más cuidado, porque las etiquetas suelen ser permanentes y borrar una localmente puede no ser lo que quieres. Las etiquetas son el tema de la lección 05-05.

Muy importante: prune borra referencias remotas, nunca ramas locales ni commits. Si tienes una rama local funcionalidad/contador-tareas, sigue ahí intacta después del prune. Solo desaparece la nota que decía "el servidor tenía esta rama".

Ha llegado el momento que anunciamos al cerrar el módulo 3.

Carla, desde su Windows 11, con Git instalado (lección 01-02), configurado (lección 01-06) y su clave SSH generada, cargada y subida (lección 04-03), abre Git Bash y escribe el comando que Bruno ejecutó en la lección 02-02:

Pero esta vez no es el mismo clon que hizo Bruno. Aquel era un repositorio de dos commits recién nacido. Este tiene meses de trabajo dentro:

Ahí está toda la historia del módulo 3, con sus fusiones a tres bandas, su squash y su conflicto resuelto, descargada íntegramente en el portátil de Carla. Puede consultar cualquier commit de cualquier momento sin conexión, porque —como sabe desde la lección 04-01— su repositorio es completo e independiente.

Y lo que dijimos en la lección 02-02 sobre lo que deja configurado el clon:

Fíjate en un detalle que confunde a mucha gente al incorporarse a un proyecto: Carla solo tiene una rama local (main), aunque el servidor tenga varias. Las demás existen en su repositorio como referencias remotas, no como ramas propias. Para trabajar en una:

Git ha visto que no existe esa rama local pero sí origin/documentacion/actualizar-notas, ha deducido lo que quería y ha creado la rama local con su seguimiento configurado. Ese comportamiento se llama DWIM y es uno de los temas de la lección 04-06.

Carla ya está operativa. Su rutina diaria será esta, y es la de cualquier persona que trabaja con un repositorio compartido:

Tres comandos por la mañana. Ese es todo el ritual.

Falta un caso, y hay que nombrarlo aunque no lo desarrollemos aquí.

Supón que Carla ha confirmado dos commits en main mientras Ana enviaba otros tres. Ahora las dos historias han divergido: cada una tiene commits que la otra no tiene. Es el escenario que estudiamos en la lección 03-01 con ramas locales, pero ahora una de las dos "ramas" está en otra máquina.

Con pull.ff only configurado:

Insistimos: esto no es un fallo, es la protección funcionando. Git se niega a decidir por ti entre fusionar y reescribir, y hace bien: son decisiones con consecuencias distintas sobre el historial del equipo.

Las salidas existen y son varias —fusionar explícitamente, reaplicar tus commits con rebase, o replantear el trabajo—, y cada una tiene sus implicaciones y sus contraindicaciones. Todo ello, con los criterios para elegir y los procedimientos completos, es el tema de la lección 09-03: Resolviendo Divergencias con el Remoto.

Aquí basta con que sepas reconocer el mensaje, que entiendas por qué aparece (las dos partes han avanzado por separado desde un ancestro común) y que tengas claro que nada se ha roto ni se ha perdido: simplemente hay una decisión pendiente.

Lo mismo ocurrirá en el sentido contrario, cuando intentes enviar y el servidor rechace tu push. Es exactamente la misma situación vista desde el otro lado, y la veremos en la lección siguiente.

Error 1: creer que git fetch no ha hecho nada porque "los ficheros siguen igual". Ha hecho justo lo que debía: descargar objetos y actualizar origin/main. Compruébalo con git log --oneline main..origin/main y verás todo lo que ha traído.

Error 2: ejecutar git pull a ciegas y sorprenderse del resultado. Si has divergido y tienes pull en modo merge, acabas de crear un commit de fusión que a lo mejor no querías. fetch + mirar + integrar cuesta quince segundos y elimina las sorpresas.

Error 3: interpretar fatal: Not possible to fast-forward como un error grave. Es pull.ff only haciendo su trabajo: hay divergencia y Git no decide por ti. Ver 09-03.

Error 4: no usar --prune nunca. Al cabo de un año tienes cuarenta referencias origin/… de ramas que se borraron hace meses, el autocompletado es inservible y git branch -r no se puede leer. Configura fetch.prune true y olvídate.

Error 5: pensar que origin/main se actualiza sola. Es un fichero de tu disco. Solo cambia con fetch, pull, clone o un push con éxito. Si un compañero te dice "ya está subido" y tú no lo ves, tu primer comando es git fetch.

Error 6: hacer pull con cambios sin confirmar y bloquearse con el error. El mensaje es claro: confirma o guarda temporalmente. Y recuerda que un fetch en esa misma situación habría funcionado sin problema.

Error 7: confundir git remote prune con git prune. Son comandos distintos: el primero limpia referencias remotas obsoletas; el segundo es una operación de mantenimiento de la base de datos de objetos que elimina objetos inalcanzables. No los mezcles.

Consejo 1: convierte git fetch --prune en tu primer comando del día. Es gratis, es seguro y te sitúa. Después decides qué hacer.

Consejo 2: guarda un alias para ver el grafo con las referencias remotas.

Con git gr ves de un golpe dónde estás tú, dónde está el servidor y qué ramas hay por medio. Los alias se tratan a fondo en la lección 06-04.

Consejo 3: usa git ls-remote para comprobar el servidor sin descargar nada. Es instantáneo y perfecto para responder a "¿está ya subido?" o "¿este remoto responde?".

Consejo 4: si vas a viajar o a quedarte sin conexión, haz git fetch --all --tags antes. Te llevas todo el trabajo del equipo en el disco y puedes revisarlo, comparar ramas y consultar el historial sin red.

Consejo 5: git fetch es seguro. Ejecútalo sin miedo. No hay ninguna situación en la que un fetch estropee algo. Interiorizarlo es lo que permite trabajar con remotos con tranquilidad.

Monta un servidor bare y dos clones que simulen a Ana y a Carla. Después:

1. Ana confirma y envía dos commits.
2. Carla, antes de hacer nada, anota el hash de su main y de su origin/main, y guarda una copia del contenido de un fichero.
3. Carla ejecuta git fetch.
4. Demuestra con comandos que: (a) origin/main ha cambiado, (b) main no, (c) el fichero del disco es idéntico y (d) los commits nuevos ya están en su base de datos de objetos.
5. Ahora integra y comprueba qué tipo de integración ha hecho Git y por qué.

Partiendo del ejercicio anterior, y sin integrar, responde con un comando a cada pregunta:

1. ¿Cuántos commits me faltan?
2. ¿Quién los ha escrito y cuándo?
3. ¿Qué ficheros modifican y con cuántas líneas cada uno?
4. ¿Qué cambia exactamente en app.js?
5. ¿Tengo yo algún commit que el servidor no tenga?
6. ¿Cómo queda el grafo con todas las referencias?

1. Crea en el servidor tres ramas además de main.
2. Clona y comprueba que aparecen las tres como referencias remotas.
3. Borra dos de ellas en el servidor.
4. Haz un git fetch normal y comprueba que las referencias fantasma siguen ahí.
5. Explica por qué el fetch no las ha eliminado.
6. Límpialas de las dos formas posibles y configura Git para que no vuelva a pasar.

Solución 1:

Exactamente el mismo hash de antes del fetch.

Misma suma de comprobación y git status --short sin ninguna línea: el directorio de trabajo está intacto.

Esta es la demostración clave: Carla puede examinar el contenido completo de commits que no ha integrado, sin conexión, porque los objetos están en su .git/objects/. Lo que no ha cambiado es su rama ni sus ficheros.

Fast-forward, y la razón está en el grafo: Carla no había confirmado nada, así que su main era un antepasado directo de origin/main. No había divergencia y no hacía falta ningún commit de fusión: bastaba con mover el puntero. Se puede comprobar formalmente:

Solución 2:

Volviendo al estado justo después del fetch y antes del merge:

El -- separa las referencias de las rutas, para que Git no dude si app.js es un fichero o una rama.

Nada. No he divergido, así que la integración será limpia. La versión compacta de la misma pregunta:

Cero commits míos exclusivos, dos suyos. (Esta sintaxis se explica a fondo en la lección 04-06.)

Una sola línea recta con main por detrás: la imagen visual de "puedo hacer fast-forward".

Solución 3:

Las dos fantasma siguen ahí. Y git remote show lo confirma:

5. Por qué el fetch no las ha eliminado: porque el refspec por defecto, +refs/heads/*:refs/remotes/origin/*, solo describe qué traer. Es una instrucción de copia, no de sincronización: dice "las ramas que existan allí, guárdalas aquí", y no dice nada sobre qué hacer con las que ya no existen. Borrar referencias es un comportamiento adicional que hay que pedir explícitamente, y Git es conservador por defecto: no elimina cosas sin que se lo mandes.

A partir de ahora, todos los fetch y pull limpian solos. Y una comprobación tranquilizadora final:

prune borra referencias remotas, nada más.

Esta lección ha deshecho la confusión más extendida de Git. Lo esencial:

• git fetch descarga objetos y actualiza tus referencias remotas. No toca el directorio de trabajo, no mueve tus ramas y no puede provocar conflictos. Es una operación completamente segura que puedes ejecutar en cualquier momento, incluso con cambios sin confirmar.
• git pull es git fetch + una integración en tu rama actual. La primera mitad es inofensiva; la segunda modifica tus ficheros y puede dar conflictos. Verlas por separado es lo que quita el misterio al comando.
• La salida c2a8f1e..b4d7e93 main -> origin/main significa: la rama main del servidor se ha guardado en tu referencia local origin/main. Tu main no se ha movido.
• FETCH_HEAD guarda qué se trajo en la última descarga, con la marca not-for-merge en las ramas que no son candidatas a integrarse. Es el mecanismo interno de pull y permite traer de una URL sin registrar remoto.
• Entre el fetch y la integración hay un hueco, y es para mirar: git log main..origin/main, git diff --stat main origin/main, git log --oneline --graph --all. Veinte segundos que eliminan las sorpresas.
• Integrar el trabajo remoto es el mismo git merge del módulo 3: fast-forward si no has divergido, fusión a tres bandas si sí. Los remotos solo cambian de dónde vienen los commits.
• Los modos de pull: --ff-only (el nuestro, por pull.ff only) se detiene ante la divergencia en lugar de decidir por ti; --no-rebase fusiona y crea commits de fusión; --rebase reaplica tus commits y se estudia en la lección 05-01.
• git fetch --prune y git remote prune eliminan las referencias de ramas ya borradas en el servidor, que un fetch normal nunca limpia. Configura fetch.prune true y olvídate. Solo borra referencias remotas: nunca ramas locales ni commits.
• Carla ya está dentro: ha clonado un repositorio con historia completa, tiene origin configurado, una rama local y referencias remotas para las demás.
• Si las historias divergen, pull --ff-only se detiene. No es un fallo: es una decisión pendiente. El tratamiento completo, en la lección 09-03.

Ya sabes recibir. Falta la otra mitad, y es la que tiene consecuencias para todo el equipo: enviar.

En la lección 04-05: Enviando Cambios veremos qué manda exactamente git push (objetos y la actualización de una referencia), qué hace ese -u que aparece en todos los tutoriales, cómo se escribe un refspec de envío y por qué se relaciona directamente con lo que estudiamos en 04-02. Y sobre todo: por qué un push puede ser rechazado, qué significa exactamente non-fast-forward, y por qué --force-with-lease es casi siempre la respuesta correcta cuando --force puede destruir el trabajo de un compañero sin dejar rastro.