La lección anterior cerró el deshacer local: reset, restore, clean, y una tabla de decisión que terminaba con una fila remitiendo aquí. Esta lección se ocupa de todo lo que ocurre entre tu repositorio y el servidor, y cierra la promesa que quedó abierta en la lección 04-05, donde vimos el rechazo non-fast-forward y solo dimos la salida básica.

El problema tiene un nombre y una definición precisa: divergencia. Y tiene una fama de complicado que no merece, porque en cuanto se dibuja el grafo la solución suele ser evidente. Lo que confunde es que el mismo estado se presenta con cuatro mensajes distintos según cómo lo descubras: un status que dice "have diverged", un pull que se niega a decidir, un push rechazado, o un compañero avisando de que le han desaparecido commits.

Vamos a ver que las cuatro son la misma situación, que hay exactamente tres formas de salir de ella, y que la elección entre las tres depende de una sola pregunta: ¿de quién es esta rama?

Y al final, el caso serio: qué hacer cuando el que reescribió el historial publicado fue otro, y tú tienes dos días de trabajo apoyados en una base que ya no existe.

1. Qué significa exactamente "han divergido"
2. Medir la divergencia
3. Los cuatro mensajes de la misma situación
4. Las tres políticas de pull y cuál elegir
5. Cómo se llega a una divergencia
6. El push rechazado: diagnóstico y salidas
7. --force-with-lease y por qué a veces no protege
8. Cuando el remoto reescribió y tú tienes trabajo encima
9. Recuperar la rama remota anterior con origin/rama@{1}
10. Historias no relacionadas: --allow-unrelated-histories
11. Coordinación: lo que hay que decir y cuándo

Dos ramas han divergido cuando cada una tiene commits que la otra no tiene. Formalmente: existe un ancestro común, y desde él salen dos caminos distintos.

Tu main tiene dos commits que el servidor no tiene. El servidor tiene tres que tú no tienes. El ancestro común es 4f8a2e6.

Compáralo con los dos casos que no son divergencia:

La palabra clave es decidir. Una divergencia no es un error: es una situación en la que Git no puede saber qué quieres y se niega a inventárselo. Todo lo que sigue son formas de tomar esa decisión.

Recuperando la lección 03-01: el ancestro común es el que Git calcula con git merge-base, y es la base de la fusión a tres bandas. Puedes verlo directamente:

Antes de resolver, mide. Estos comandos no modifican nada.

fetch actualiza origin/main sin tocar tu main (lección 04-04). Sin esto, estás razonando sobre una foto vieja del servidor.

Los tres puntos son fundamentales: A...B es la diferencia simétrica, los commits que están en una rama pero no en la otra. --left-right los separa por lado.

Con la rama de seguimiento configurada (lección 04-06), basta:

Esto es lo que de verdad permite decidir:

< es el lado izquierdo (tu main), > el derecho (origin/main).

Y la pregunta que decide si va a haber conflictos:

Si los conjuntos de ficheros no se solapan, la integración será limpia.

Según cómo llegues a la divergencia, Git te la cuenta de forma distinta. Reconocerlas todas es media lección.

Es el diagnóstico puro. Los números coinciden con rev-list --left-right --count.

Desde Git 2.27, pull se niega a elegir por ti:

Esto es bueno. Antes, pull hacía una fusión silenciosa y llenaba el historial de commits "Merge branch 'main' of git.ejemplo.es..." que nadie había pedido. Ahora te obliga a tener una política, y eso es el apartado 4.

Es la misma información con menos palabras: hay divergencia y tu política dice "no decidas por mí". No es un fallo (lección 04-04, error 3).

O, en su variante más alarmante:

Las dos dicen lo mismo: el servidor tiene commits que tú no tienes, y aceptar tu envío los dejaría inalcanzables. Es una protección del servidor, no un fallo tuyo. Es el apartado 6.

git pull es fetch + integración (lección 04-04). La política decide qué integración.

Visualmente, sobre el mismo punto de partida:

La configuración recomendada para la mayoría de la gente:

O, si tu equipo trabaja con ramas cortas y quiere historial lineal (que es lo que hace Ana en gestor-tareas):

rebase.autoStash evita el "cannot pull with rebase: You have unstaged changes", que es la queja más frecuente contra pull --rebase.

La regla de oro sigue vigente (lección 05-01): pull --rebase reescribe tus commits locales, que aún no has publicado. Eso es legítimo. Lo que nunca hay que hacer es rebasar commits que ya están en el servidor y otros pueden tener.

Y un ajuste que evita un error clásico:

Si tenías commits fixup! pendientes (lección 05-02), no se aplastarán por sorpresa durante un pull. Compruébalo en tu configuración: si lo tienes activado sin saberlo, un pull --rebase puede reorganizarte commits.

Entender la causa importa, porque determina cuál de las salidas es correcta.

Ana confirmó en local mientras Bruno publicaba lo suyo. Nadie ha hecho nada mal. Es el funcionamiento normal de un sistema distribuido con varias personas.

Salida: integrar (merge o rebase, según la política) y enviar. Sin drama.

Carla publicó GT-247, se dio cuenta de una errata en el mensaje y ejecutó git commit --amend.

Qué ha pasado. --amend no modifica el commit: crea uno nuevo con distinto hash y mueve la rama (lección 09-01, apartado 5.3). El commit original sigue en el servidor. Local y remoto tienen ahora un commit cada uno que el otro no tiene: divergencia de 1 y 1.

Salida: si la rama es solo suya, push --force-with-lease. Si no, hay que integrar, y el resultado es feo (el commit aparecería dos veces).

Bruno hizo git reset --hard HEAD~2 sobre una rama publicada para "quitar dos commits", y después trabajó dos horas más.

Divergencia de 2 y 2. Y aquí hay una decisión de fondo: ¿los commits C y D deben desaparecer del proyecto, o no?

Salida: si deben desaparecer y la rama es suya, --force-with-lease. Si la rama es compartida, la respuesta correcta era git revert (lección 05-06) y no reset; ahora toca integrar y revertir.

Diego hizo un rebase -i sobre main para "limpiar el historial" y forzó el push. Todos los que tenían main descargado se encuentran con una divergencia que no han provocado.

Es el caso serio, y tiene apartado propio: el 8.

Ana y Carla trabajan a la vez en GT-241. Ambas hacen pull --rebase. Cada rebase reescribe los commits de la otra. El resultado es una espiral de commits duplicados que se resuelve mal.

Salida: en ramas realmente compartidas, pull.rebase false. La política tiene que ser por rama, no por costumbre.

Este es el cierre de lo prometido en la lección 04-05.

Con esas cuatro respuestas ya sabes qué salida corresponde.

Con pull configurado:

Si aparecen conflictos durante el rebase, la mecánica es la de la lección 05-01, incluida la inversión de ours/theirs. Y si te agobias:

Solo si se cumplen las tres condiciones:

1. La rama es de funcionalidad y nadie más la usa.
2. Lo que hay en el servidor son versiones antiguas de tus propios commits.
3. Has comprobado el punto 3 del diagnóstico y no hay commits de otra persona.

El + delante indica que ha sido un envío forzado.

Nunca --force a secas. La diferencia es el apartado 7.

A veces la respuesta correcta es no forzar y no integrar, sino publicar en otro sitio:

Especialmente útil si la rama tiene una pull request abierta con comentarios de revisión (lección 07-02): forzar puede dejar los comentarios huérfanos. Publicar una rama nueva conserva todo y permite comparar con git range-diff (lección 07-02).

Recordando la lección 04-05: --force-with-lease solo fuerza si el servidor está donde tú crees que está. Compara la punta remota real con tu copia local de la rama de seguimiento (refs/remotes/origin/GT-241).

Ese stale info significa: "el servidor no está donde tu origin/GT-241 dice; alguien ha publicado algo desde tu último fetch". Es exactamente la protección funcionando: te ha evitado destruir el trabajo de otro.

Y aquí está el detalle que casi nadie conoce, y que hay que entender bien:

Si haces git fetch justo antes del --force-with-lease, la protección desaparece.

Porque fetch actualiza origin/GT-241 con lo que hay en el servidor ahora mismo, incluidos los commits nuevos de tu compañero. Tu "arrendamiento" (lease) pasa a coincidir con la realidad, la comprobación pasa, y fuerzas encima de trabajo que nunca has visto.

Lo peor es que es una secuencia razonable: "voy a actualizar antes de forzar" suena a buena práctica. Y muchos IDE hacen fetch automáticamente en segundo plano, así que puede pasarte sin que tú escribas el comando.

Git 2.30 añadió la opción que arregla el agujero:

--force-if-includes comprueba, además, que los commits remotos que vas a sobrescribir están incorporados en tu historial local, mirando tu reflog. Es decir: exige que hayas visto e integrado lo que estás a punto de reemplazar, no solo que lo hayas descargado.

Configúralo como comportamiento por defecto:

Con eso, cada --force-with-lease que ejecutes lleva la comprobación extra automáticamente. Es una línea de configuración que elimina una clase entera de accidentes.

Y la variante explícita, cuando quieres ser absolutamente preciso:

Verboso, pero no hay forma de equivocarse.

Este es el caso serio, y el que produce más pánico. Merece el procedimiento completo.

La situación. Diego hizo un rebase -i sobre main para limpiar el historial y forzó el push. Ana tenía main descargado y, encima, tres commits de GT-241 que aún no había publicado.

Lo primero: no has perdido nada. Tus commits siguen en tu repositorio, íntegros. Y los commits antiguos de main también los tienes tú en local, aunque el servidor ya no los tenga. De hecho, tu clon es ahora la única copia de la versión anterior, y eso te da una posición sólida.

Los mensajes se repiten en las dos ramas, con hashes distintos. Ese es el patrón inequívoco de un historial reescrito. Confírmalo:

git range-diff (lección 07-02) compara dos series de commits y dice si el contenido es el mismo:

Los dos primeros son idénticos (=); el tercero cambió (!) y te enseña exactamente qué. Esta es la información que necesitas antes de decidir nada.

Dos segundos. A partir de aquí, nada de lo que hagas es irreversible.

El comando que resuelve exactamente esto es el --onto de la lección 05-01. Su forma es:

que se lee: "coge los commits de <rama> que estén después de <base-antigua> y reaplícalos sobre <nueva-base>".

En nuestro caso:

• Nueva base: origin/main (el historial nuevo).
• Base antigua: 7d3a8f4 (el main viejo del que colgaba tu rama).
• Rama: GT-241.

Tus tres commits, con hashes nuevos, sobre la base nueva. Ni un commit duplicado.

Cómo encontrar la base antigua si no la tienes anotada:

Tu main local todavía tiene la versión vieja. Como no tenías nada propio en main (todo tu trabajo estaba en GT-241), simplemente aliniéalo:

Si sí tenías commits propios en main, no hagas eso: sácalos primero a una rama (git branch mis-commits-main) y trasplántalos con el mismo --onto.

Tres =: el contenido de tus commits es idéntico al de antes del trasplante. Nada se ha perdido ni alterado. Ahora puedes borrar el respaldo con tranquilidad:

Y ejecuta las pruebas antes de publicar: el rebase ha reaplicado tu código sobre una base distinta, y aunque no haya habido conflictos, puede haber incompatibilidades semánticas.

Si tus commits de GT-241 ya estaban en el servidor, después del rebase tu rama diverge de origin/GT-241. Como GT-241 es tuya:

Un detalle que salva situaciones y que casi nadie conoce: las ramas de seguimiento remotas también tienen reflog.

Dos cosas valiosísimas en esa salida:

1. forced-update es la prueba de que alguien reescribió el historial publicado. Si dudabas de qué pasó, ahí está la evidencia con su fecha.
2. origin/main@{1} es dónde estaba el main del servidor antes de la reescritura.

Esto es lo que permite reconstruir lo que el servidor tenía antes, y es la razón por la que, cuando alguien fuerza y destruye trabajo, cualquier compañero que tuviera la rama descargada puede devolverlo:

Y también con fechas:

Ese es exactamente el mecanismo del reflog, cuyo tratamiento completo —incluida la sintaxis @{n} frente a @{tiempo} y los límites de caducidad— es la lección 09-04.

Qué significa. Las dos ramas no tienen ningún ancestro común. No es una divergencia: es que son dos árboles genealógicos completamente independientes, cada uno con su propio commit raíz.

Antes de nada, comprueba que es el caso benigno:

Si el remoto solo tiene el commit inicial de la plataforma:

Probablemente conflicte en README.md: resuélvelo con normalidad (lección 03-05) y confirma.

Si el remoto tiene el proyecto de verdad y tu historia local es la sobrante:

Y si alguien ha publicado otro proyecto encima del vuestro, esto es un incidente: no fusiones nada, avisa al equipo, y usa origin/main@{1} del apartado 9 (o el clon de cualquier compañero) para restaurar. La lección 09-05 trata el uso de otros clones como copia de seguridad.

Nunca ejecutes --allow-unrelated-histories "porque Git se queja". Esa negativa es una comprobación de cordura muy útil: Git te está diciendo que esas dos cosas no tienen nada que ver. Averigua por qué antes de saltártela.

La parte no técnica, que es la que más tiempo ahorra.

Antes de reescribir algo compartido:

1. Avisa antes, no después. Un mensaje de treinta segundos en el canal del equipo: "Voy a forzar main a las 16:00 para quitar el volcado de la base de datos del historial. No hagáis pull hasta que avise."
2. Di qué tienen que hacer los demás. Aunque sea obvio para ti, no lo es para quien está a otra cosa:

   Después del aviso, cada uno:
     git fetch origin
     git switch main
     git reset --hard origin/main
   Si tenéis ramas con commits propios, avisadme antes de tocar nada
   y hacemos el rebase --onto juntos.
   

3. Hazlo en un momento de poca actividad. Nunca un viernes por la tarde, nunca durante una entrega.
4. Confirma cuando termine. El silencio genera pull a ciegas.

Cuando ya ha pasado y no avisaste:

1. Avisa igualmente, cuanto antes. El coste de decir "he forzado main, no hagáis pull" a los cinco minutos es cero. A las cinco horas es una tarde de trabajo para tres personas.
2. Ofrece el procedimiento del apartado 8, no un "arregladlo".
3. Si has destruido trabajo ajeno, el apartado 9 lo recupera desde cualquier clon del equipo. No está perdido.

Prevención estructural (lección 07-06):

Una rama protegida convierte todo este apartado en innecesario. Si main no acepta --force, el problema no puede ocurrir. Es la medida más rentable de la lección.

Y en local, una protección personal:

Error 1: responder a un push rechazado con --force. El rechazo significa que el servidor tiene commits que tú no tienes. Forzar los destruye. Diagnostica primero: git log --oneline HEAD..@{u} dice de quién son.

Error 2: razonar sobre origin/main sin haber hecho fetch. origin/main es una foto local que puede tener horas. Todo diagnóstico empieza por git fetch.

Error 3: git fetch justo antes de --force-with-lease. Anula la protección. Usa --force-if-includes, o configúralo con push.useForceIfIncludes true.

Error 4: usar pull --rebase en una rama que otra persona también tiene. Reescribe commits publicados y genera duplicados en cadena. La política debe ser por rama, no por costumbre.

Error 5: hacer --allow-unrelated-histories sin mirar qué hay al otro lado. Puedes acabar fusionando otro proyecto entero en el tuyo. Mira git log origin/main primero.

Error 6: git reset --hard origin/main sin comprobar qué tienes por delante. git log --oneline @{u}..HEAD cuesta un segundo y te dice exactamente qué vas a tirar.

Error 7: rehacer el trabajo a mano tras una reescritura ajena. git rebase --onto lo trasplanta en un comando y range-diff demuestra que no se ha alterado nada.

Error 8: forzar una rama con una pull request abierta llena de comentarios. Puede dejar la revisión huérfana. Considera publicar una rama nueva.

Error 9: no avisar. El coste técnico de una reescritura compartida es pequeño; el coste social de no anunciarla, enorme.

Consejo 1: git status -sb como reflejo. Una línea que dice [ahead N, behind M] y resuelve la mitad de las dudas.

Consejo 2: pull.ff only como valor global. Te obliga a mirar antes de integrar, y evita commits de fusión que nadie pidió.

Consejo 3: push.useForceIfIncludes true. Una línea de configuración que elimina el agujero del --force-with-lease.

Consejo 4: git range-diff antes y después de cualquier reescritura. Es la prueba objetiva de que el contenido no ha cambiado.

Consejo 5: recuerda origin/rama@{1}. El historial anterior del servidor sigue en tu reflog remoto, y con él se restaura lo que otro destruyó.

Consejo 6: protege main en el servidor. Es la única solución que hace imposible el problema, en lugar de tratarlo.

1. Monta un remoto local con git init --bare y clónalo dos veces (simulando a Ana y a Bruno).
2. Desde el clon de Bruno, haz dos commits y publícalos.
3. Desde el de Ana, sin hacer fetch, haz dos commits distintos.
4. Ejecuta git fetch y mide la divergencia con git status -sb, git rev-list --left-right --count y git log --left-right --oneline.
5. Intenta git push y transcribe el mensaje exacto.
6. Resuélvelo con pull --rebase y comprueba con git log --graph que el historial ha quedado lineal.
7. Repite todo el ejercicio con pull --no-rebase y compara los dos grafos resultantes.

1. Con el mismo montaje, haz que Ana publique un commit en GT-241.
2. Ana ejecuta git commit --amend sobre ese commit (sin publicar todavía).
3. Mientras tanto, Bruno publica un commit nuevo en GT-241.
4. Ana ejecuta git push --force-with-lease. Anota el resultado y explícalo.
5. Ana ejecuta git fetch y vuelve a intentarlo. Anota el resultado y explica por qué ha cambiado.
6. Comprueba que el commit de Bruno ha desaparecido del servidor y recupéralo usando origin/GT-241@{1} desde el clon de Bruno.
7. Repite el paso 5 con --force-if-includes y comprueba que ahora sí protege.

1. Monta un remoto con tres commits en main y clónalo dos veces.
2. Desde el clon de Ana, crea GT-241 sobre main con tres commits propios (sin publicarla).
3. Desde el clon de Diego, haz git rebase -i sobre main para modificar el mensaje del segundo commit, y fuerza el push.
4. Ana hace fetch y diagnostica la situación con git log --graph --all y git range-diff.
5. Ana trasplanta GT-241 con git rebase --onto y alinea su main.
6. Verifica con range-diff que sus tres commits son idénticos en contenido.
7. Comprueba en git reflog show origin/main que queda registrado el forced-update.

Solución 1:

Lineal, sin bifurcaciones. Sus dos commits tienen hashes nuevos (b52c9d1 → 8f2d6a1): el rebase los ha recreado sobre la base nueva.

Solución 2:

La protección ha funcionado. El origin/GT-241 de Ana apunta a su commit original; el servidor está en el commit de Bruno. Como no coinciden, Git se niega.

Ha pasado. Y ha destruido el commit de Bruno. El fetch actualizó origin/GT-241 al commit de Bruno; el "arrendamiento" pasó a coincidir con la realidad; la comprobación se satisfizo. Ana nunca vio el trabajo de Bruno y aun así lo sobrescribió.

En realidad Bruno ni siquiera necesita el reflog: tiene el commit en su rama local. Su GT-241 local sigue intacto:

Y para devolverlo al servidor haría falta integrarlo con la versión enmendada de Ana —un cherry-pick del commit de Bruno sobre la rama nueva (lección 05-03)—, coordinándolo entre los dos.

Ahora sí protege, incluso después del fetch. La comprobación adicional exige que los commits remotos que se van a sobrescribir estén incorporados en el historial local de Ana, no solo descargados. Y no lo están: nunca los integró.

Solución 3:

Anota ese 7d3a8f4: es la base antigua.

Dos líneas paralelas con los mismos mensajes: historial reescrito.

Solo cambió un mensaje; el contenido es idéntico. Diagnóstico completo en un comando.

Tres =. Contenido idéntico, base nueva, cero commits duplicados.

forced-update con su fecha, y origin/main@{1} guardando el historial anterior del servidor. Si hubiera hecho falta restaurarlo, ahí estaba.

Las divergencias dejan de asustar en cuanto se ven como lo que son: una situación en la que Git no puede decidir por ti.

• Divergir significa que cada rama tiene commits que la otra no tiene. Se mide con git status -sb y con git rev-list --left-right --count main...origin/main, y se entiende mirando los dos lados con git log --left-right. Todo diagnóstico empieza por git fetch.
• Los cuatro mensajes son la misma situación: el "have diverged" de status, el "You have divergent branches" de pull, el "Not possible to fast-forward" de pull.ff only y el non-fast-forward del push.
• Tres políticas de pull: merge para ramas realmente compartidas, rebase para las tuyas, ff-only cuando prefieres decidir a mano. La elección es por rama, no por costumbre.
• El push rechazado se responde diagnosticando, no forzando: git log --oneline HEAD..@{u} dice de quién son los commits del servidor. Si son de otro, se integra. Si son versiones viejas de los tuyos y la rama es solo tuya, se fuerza con --force-with-lease.
• --force-with-lease no protege si has hecho fetch justo antes, porque el arrendamiento se actualiza con lo que aún no has visto. --force-if-includes lo arregla; push.useForceIfIncludes true lo deja puesto para siempre.
• Cuando otro reescribe el historial publicado y tú tienes trabajo encima, el procedimiento es: respaldar con git branch, trasplantar con git rebase --onto <nueva-base> <base-vieja> <rama>, alinear main con reset --hard origin/main, y verificar con git range-diff que el contenido no ha cambiado.
• Las ramas remotas también tienen reflog. origin/main@{1} guarda dónde estaba el servidor antes de la reescritura, y forced-update es la evidencia de que ocurrió. Con eso, cualquier clon del equipo puede restaurar lo destruido.
• refusing to merge unrelated histories no es divergencia: son dos árboles sin ancestro común. Mira qué hay al otro lado antes de usar --allow-unrelated-histories.
• Y lo que más ahorra: avisar antes, y proteger main en el servidor para que el problema no pueda ocurrir.

Queda una idea que ha aparecido en casi todos los apartados sin desarrollarse: el reflog. Ha sido la fuente del ORIG_HEAD de la lección anterior, del origin/main@{1} de esta, y de la promesa que llevamos abierta desde la lección 03-06 ("-D es recuperable") y la 05-01 ("un rebase desastroso se puede deshacer").

Toca desarrollarlo entero: qué es exactamente, dónde vive, cuánto dura, cómo se lee, y el recetario completo de recuperación —el reset --hard que se llevó tres días, la rama borrada con -D, el rebase que salió mal, el stash eliminado— más lo que hacer cuando ni siquiera el reflog basta.

Continúa en la lección 09-04: Recuperando Confirmaciones Perdidas.