Ha pasado lo que tenía que pasar. Bruno publicó ayer en main un commit que cambia cómo se guardan las tareas en localStorage, y esta mañana Ana ha descubierto que a los usuarios que ya tenían tareas guardadas se les vacía la lista al abrir la aplicación. El commit está en git.ejemplo.es desde hace catorce horas, Ana y Carla lo tienen descargado, y encima hay tres commits más encima suyo.

Todo lo que hemos aprendido en este módulo reescribe historial, y la regla de oro lo prohíbe expresamente en esta situación: ese commit ya es público. No se puede rebasar, no se puede eliminar con un rebase -i, no se puede hacer desaparecer.

Git tiene una respuesta para esto, y es elegante precisamente porque no lucha contra la inmutabilidad sino que la acepta: no se borra el commit, se añade otro que aplica el cambio contrario. El historial crece en lugar de encogerse, nadie tiene que forzar nada, y queda constancia pública de que aquello se deshizo y por qué.

Eso es git revert, y es la única forma segura de deshacer algo que ya está publicado. Con ella cerramos el módulo.

1. Qué hace git revert
2. Revirtiendo el commit de Bruno
3. revert frente a reset frente a --amend
4. Revertir varios commits y rangos
5. -n: agrupar varias reversiones en un commit
6. Conflictos al revertir
7. Revertir un commit de fusión: -m 1 y -m 2
8. El problema de la rama revertida que ya no vuelve a entrar
9. Revertir una reversión
10. Cuándo revertir y cuándo no

Git calcula el diff que introdujo <sha>, lo invierte (lo que añadía, lo quita; lo que quitaba, lo añade) y crea un commit nuevo con ese cambio inverso sobre la punta de tu rama.

El commit 4f8a2e6 (destacado) es el que rompió las cosas. 3e7f1a8 es su reversión: deshace su efecto sin tocar nada de lo que hay en medio. Los seis commits siguen ahí, en el mismo orden, con los mismos hashes.

Las tres propiedades que lo distinguen de todo lo demás del módulo:

Ese último punto se malinterpreta a menudo. Alguien dice "quiero que desaparezca, no que quede en el historial". Pero que quede constancia es lo correcto: dentro de seis meses, cuando alguien mire por qué esa funcionalidad no está, el historial se lo dirá. Un commit borrado no explica nada; un commit revertido con un buen mensaje explica todo.

Situación de partida:

El culpable es 4f8a2e6. Primero, mirarlo:

Ahí está el fallo: se cambió la clave de almacenamiento sin migrar los datos existentes. Ahora, la reversión:

Git abre el editor con un mensaje propuesto:

Ana lo completa, porque el mensaje por defecto dice qué pero no por qué:

El diff del nuevo commit es exactamente el inverso del original:

Y ahora lo mejor de todo:

Un push normal, sin --force, sin --force-with-lease, sin avisar a nadie de que reescriba nada. Carla y Bruno harán git pull, recibirán un commit más y todo funcionará. Ese es el valor de revert: deshacer sin coste social.

Opciones de git revert:

Las tres "deshacen" cosas y se confunden constantemente. La diferencia clave es si tocan el historial existente, y eso determina cuál puedes usar sobre trabajo publicado.

La forma de decidir, en una pregunta: ¿lo que quiero deshacer está ya en el servidor y otros lo pueden tener?

• Sí → git revert. No hay alternativa segura.
• No → reset o --amend son más limpios, porque el resultado no arrastra un commit de deshacer que a nadie le importa.

Un ejemplo que aclara la diferencia de resultado. Historial A → B → C, queremos quitar B:

Fíjate en el detalle importante del reset: también se lleva C, porque mueve la rama a A y todo lo posterior queda huérfano. Para quitar solo B conservando C hay que rebasar, no resetear.

git reset es mucho más de lo que cabe aquí. Tiene tres modos —--soft, --mixed y --hard— que se comportan de forma muy distinta según a cuáles de las tres zonas de la lección 01-03 afecten, y es la herramienta central para deshacer trabajo local. Todo eso, con las tablas y los procedimientos completos, es el tema de la lección 09-02: Deshaciendo Cambios. Aquí solo necesitábamos el contraste conceptual: reset reescribe, revert no.

git revert acepta varios commits y rangos, con la misma notación de la lección 02-06:

Un detalle fundamental: Git los revierte en orden inverso, del más reciente al más antiguo. Es lo correcto y lo que evita conflictos innecesarios: si C se apoya en B, hay que deshacer C antes que B. Por eso git revert HEAD~3..HEAD produce tres commits de reversión en este orden:

Tres commits deshechos, tres commits de reversión, y un historial que cuenta exactamente lo que pasó. Si prefieres que sea uno solo, pasamos al siguiente apartado.

Tres commits de reversión seguidos suelen ser ruido: lo que ocurrió conceptualmente es una decisión ("quitamos la funcionalidad del filtro"), no tres. -n (--no-commit) aplica los cambios inversos al índice sin confirmar, y tú confirmas al final:

Un solo commit, un solo mensaje, una sola decisión. Es casi siempre la mejor forma de revertir un conjunto de commits relacionados.

Mientras estás en medio de un revert -n, el repositorio está en un estado especial (hay un fichero .git/REVERT_HEAD). Si te arrepientes:

Un revert es, por dentro, una fusión: Git intenta aplicar un parche inverso sobre un contexto que puede haber cambiado desde entonces. Si el código que quieres deshacer ha sido modificado después, conflictúa.

La mecánica de resolución es la de siempre (lección 03-05). Lo específico:

Como en el cherry-pick (lección 05-03), aquí ours y theirs NO están invertidos: ours es tu rama, theirs es el cambio inverso que se intenta aplicar. La inversión era una peculiaridad del rebase.

Y una advertencia que conviene interiorizar: cuando un revert conflictúa, párate a pensar. El conflicto te está diciendo que alguien construyó encima de lo que quieres deshacer. Revertir a la fuerza puede dejar código que llama a una función que acaba de desaparecer. Comprueba quién depende de eso antes de continuar:

-S es la búsqueda por pickaxe de la lección 02-06, y aquí es exactamente la herramienta adecuada.

Este es el caso que hace fallar a todo el mundo la primera vez.

Por qué falla. Revertir significa aplicar el diff inverso. Pero un commit de fusión tiene dos padres, y por tanto dos diffs posibles: uno contra el primer padre y otro contra el segundo. Git no puede adivinar cuál quieres, así que se niega y te obliga a decirlo.

Los padres del commit de fusión, en orden:

El primer padre es siempre la rama de destino, porque el commit de fusión se creó estando tú en ella. El segundo (y siguientes, en un octopus merge) son las ramas traídas.

-m 1 significa: "quédate con la línea del padre 1", es decir, deshaz todo lo que aportó la rama fusionada y conserva main como estaba. Es lo que quieres el 99 % de las veces.

-m 2 haría lo contrario: deshacer lo que aportó main y conservar la rama. Es una operación rarísima y casi siempre indica que te has equivocado de comando.

La regla mnemotécnica: -m 1 = "conserva la rama principal, tira lo que traje".

Consejo práctico: antes de revertir una fusión, mira sus padres. git log --format='%h %p %s' -1 <sha> te los da en un segundo, y git show <sha>^1 / git show <sha>^2 te enseña cada uno. Con dos comandos evitas el error.

Aquí llega la consecuencia sutil, la que muerde semanas después, y la razón por la que revertir una fusión merece un apartado propio.

Bruno revirtió la fusión de funcionalidad/filtro-pendientes. Dos semanas después arregla el problema del contador y quiere volver a integrar la rama:

"Already up to date", y en main no aparece nada del filtro. Desconcertante.

Por qué pasa. Recuerda la fusión a tres bandas de la lección 03-03: Git busca el ancestro común y compara. Pero el ancestro común de main y funcionalidad/filtro-pendientes es ahora la propia fusión revertida (c2a8f1e), porque esa fusión sigue en el historial y hace que todos los commits de la rama sean alcanzables desde main.

Desde el punto de vista del grafo, esos commits ya están integrados. Que su contenido se deshiciera después con 4d7c1a9 es irrelevante para el cálculo: Git razona sobre alcanzabilidad, no sobre contenido.

El commit destacado es la reversión. La rama está conectada al grafo de main; el contenido, no.

Y si Bruno añade commits nuevos a la rama y fusiona otra vez, el resultado es peor todavía: entran solo los commits nuevos, sobre un main al que le falta la base que aquellos esperaban. Código que llama a funciones que no existen, y ningún conflicto que lo avise.

Las tres soluciones, en orden de preferencia:

A. Revertir la reversión. La más simple y la que se usa casi siempre:

Eso devuelve el contenido de la rama a main. A partir de ahí, los commits nuevos que Bruno haga en la rama se fusionarán con normalidad. El historial queda un poco cómico —un "Revert del Revert"— pero es correcto, honesto y seguro. Si quieres, edita el mensaje para explicarlo:

B. Rehacer la rama sobre el main actual. Si la rama era corta, crear una rama nueva desde main y traer los commits con git cherry-pick (lección 05-03) da un historial más limpio:

Los commits nuevos tienen hashes nuevos, no son alcanzables desde main, y la fusión posterior funciona con normalidad.

C. Forzar la fusión ignorando el ancestro. Existe, pero casi nunca es buena idea; la mencionamos para que la reconozcas si la ves:

La lección de fondo, y merece subrayarse:

Revertir una fusión deshace el contenido, no la topología. El grafo sigue diciendo que esa rama se integró.

Por eso, cuando una rama entera hay que quitarla y se sabe que volverá, muchos equipos prefieren revertir los commits individuales en lugar de la fusión, o directamente no fusionar hasta estar seguros. Y por eso conviene saber esto antes de revertir una fusión, no después.

Ya lo hemos usado en el apartado anterior, pero conviene enunciarlo: una reversión es un commit normal y corriente, así que se puede revertir.

El resultado es que el cambio original vuelve. Es la forma canónica de decir "me precipité al deshacer esto".

Y como es simétrico, funciona tantas veces como quieras: revertir la reversión de la reversión deshace otra vez. Cada paso es un commit nuevo, nadie fuerza nada y el historial cuenta la secuencia completa de decisiones. Poco elegante, pero rigurosamente seguro.

Y dos consideraciones de criterio que no son técnicas:

Revierte pronto. Si algo está roto en main, revertir primero y diagnosticar después es casi siempre lo correcto. Un main roto bloquea a todo el equipo; el commit revertido no se pierde y se puede reintroducir arreglado. Es una decisión de servicio, no de orgullo.

Escribe por qué. El mensaje automático (This reverts commit ...) dice qué se deshizo pero no por qué. Añadir tres líneas explicando el motivo y qué haría falta para volver a intentarlo convierte una reversión en información útil dentro de seis meses. Las convenciones de mensajes son el tema de la lección 08-01, pero este caso concreto vale la pena mencionarlo aquí: la reversión sin explicación es una de las entradas más frustrantes que se puede encontrar en un historial.

Error 1: usar reset en lugar de revert sobre trabajo publicado. Es la vía rápida al escenario del apartado 9 de la lección 05-01: push --force, compañeros con historiales divergentes y una tarde de coordinación. Si está en el servidor, revert.

Error 2: intentar revertir una fusión sin -m. Git falla con un mensaje claro. Recuerda: -m 1 en el 99 % de los casos.

Error 3: confundir el orden de los padres. -m 1 es la rama en la que estabas (normalmente main); -m 2 es la que trajiste. Comprueba con git show --format='%h %p %s' -s <sha> antes de decidir.

Error 4: dar por hecho que tras revertir una fusión la rama volverá a entrar sola. No lo hará: Already up to date. Hay que revertir la reversión o rehacer la rama.

Error 5: aceptar el mensaje por defecto sin más. Dice qué, no por qué. Treinta segundos de explicación ahorran una investigación futura.

Error 6: revertir un commit que otros construyeron encima sin comprobar dependencias. Puedes dejar el código llamando a algo que ya no existe. Usa git log -S y git log <sha>..HEAD -- <fichero> antes.

Error 7: revertir en la rama equivocada. git revert actúa sobre la rama actual. Comprueba con git status antes de lanzarlo, sobre todo si vienes de mirar otra rama.

Consejo 1: mira siempre el commit antes de revertirlo. git show <sha> cuesta tres segundos y te dice si el cambio es autocontenido o si arrastra medio proyecto.

Consejo 2: para varios commits relacionados, usa -n y confirma una sola vez. Una decisión, un commit.

Consejo 3: si el revert conflictúa, léelo como una señal. Alguien construyó encima. Puede que la salida correcta no sea revertir sino corregir hacia delante.

Consejo 4: revertir es reversible. Si te precipitas, git revert sobre la reversión lo devuelve todo. Nada de lo que hagas con este comando es irrecuperable.

Consejo 5: en main, revertir primero y pensar después. Restablecer el servicio es prioritario; el diagnóstico puede hacerse con calma en una rama.

En un repositorio con cinco commits, de los cuales el tercero introduce un fallo:

1. Revierte el tercer commit con un mensaje que explique el motivo.
2. Demuestra que ninguno de los hashes anteriores ha cambiado.
3. Demuestra que el contenido del fichero es el que había antes de ese commit, salvo lo que aportaron el cuarto y el quinto.
4. Compara conceptualmente con lo que habría pasado usando git reset --hard sobre el segundo commit (no hace falta ejecutarlo en la rama principal: hazlo en una copia).

1. Crea una rama con dos commits y fusiónala en main con --no-ff.
2. Añade un commit más a main.
3. Revierte la fusión con -m 1 y comprueba que el contenido de la rama ha desaparecido.
4. Intenta fusionar la rama otra vez y observa el mensaje.
5. Resuélvelo revirtiendo la reversión y comprueba que el contenido vuelve.
6. Dibuja (o describe) el grafo resultante.

Con una rama que tenga cuatro commits sobre main, revierte los tres últimos en un único commit usando -n. Verifica con git show --stat que el commit resultante contiene la reversión de los tres, y con git diff que el estado del proyecto coincide con el que había tras el primero.

Solución 1:

Los cinco commits originales conservan sus hashes; solo se ha añadido uno arriba.

Ha desaparecido ERROR y se conservan las líneas de Cuatro y Cinco.

El reset se ha llevado por delante Tres, Cuatro y Cinco: mueve la rama, no deshace un cambio concreto. Y si esa rama estuviera publicada, el push sería rechazado y haría falta forzarlo.

Solución 2:

filtro.js ha desaparecido: el contenido de la rama está deshecho.

Ahí está el problema: el grafo dice que ya está integrada.

El contenido ha vuelto.

Ocho commits que cuentan la historia completa: se integró, se quitó, se volvió a poner. Nada se ha reescrito y nadie ha forzado nada.

Solución 3:

Un solo commit de reversión y un estado idéntico al del primer commit de la serie, sin haber tocado ningún hash.

git revert es la pieza que faltaba: la forma de deshacer que respeta la regla de oro. Lo esencial:

• Revertir no borra: añade. Git crea un commit nuevo con el cambio inverso. Ningún hash existente cambia, no hace falta forzar el push y queda constancia pública de la decisión.
• Es la única forma segura de deshacer algo publicado. reset y --amend reescriben historial y solo valen para trabajo que aún es tuyo; la lección 09-02 desarrolla reset a fondo.
• Admite varios commits y rangos, que revierte del más reciente al más antiguo; -n permite acumular varias reversiones y confirmarlas como una sola decisión.
• Los conflictos se resuelven como siempre, con --continue, --skip y --abort, y aquí ours/theirs no están invertidos. Un conflicto al revertir suele significar que alguien construyó encima: párate a mirar.
• Revertir una fusión exige -m para elegir el padre principal: -m 1 (la rama en la que estabas, casi siempre main) o -m 2 (la que trajiste, rarísimo).
• Revertir una fusión deshace el contenido, no la topología. La rama sigue siendo alcanzable, así que volver a fusionarla dice Already up to date. Se resuelve revirtiendo la reversión, o rehaciendo la rama con cherry-pick.
• Todo es reversible: una reversión es un commit normal y se puede revertir a su vez.
• Y el criterio: en main, revierte primero y diagnostica después, y explica siempre por qué.

Con esta lección cierras el bloque de operaciones avanzadas. Repasando lo que ha cambiado en tu forma de trabajar:

• git rebase para reaplicar commits sobre otra base y obtener un historial lineal, sabiendo que crea commits nuevos.
• git rebase -i para reordenar, unir, dividir, renombrar y eliminar commits antes de publicarlos, con --fixup/--autosquash como flujo diario y --exec como red de validación.
• git cherry-pick para trasplantar commits concretos entre ramas que no se van a fusionar, con -x para dejar rastro y git cherry para detectar duplicados.
• git stash para apartar trabajo a medias durante minutos u horas, con -u para lo sin seguimiento y git stash branch cuando ya no encaja.
• Las etiquetas anotadas para marcar versiones de forma permanente, con SemVer, --follow-tags y git describe.
• git revert para deshacer lo publicado sin reescribir nada.

Y sobre todas ellas, la regla de oro: no reescribas historial que ya has publicado y otros pueden tener. Rebase e interactivo, antes de publicar. Cherry-pick y revert, siempre seguros. Es la línea que separa el uso experto del uso temerario.

El equipo ya sabe construir el historial y manipularlo con criterio. Lo que le falta ahora es aprender a sacarle partido.

Porque el historial de gestor-tareas es una base de datos enorme de información que hasta ahora apenas hemos consultado. En ella está escrito quién escribió cada línea y por qué, en qué commit exacto dejó de funcionar algo que antes funcionaba, y qué comprobaciones debería pasar cada commit antes de existir. Y hay problemas nuevos: el proyecto empieza a depender de una biblioteca interna que vive en su propio repositorio, y Carla necesita trabajar en dos ramas a la vez sin pasarse el día haciendo stash.

En el módulo 6: Herramientas y Técnicas de Git veremos los hooks para automatizar comprobaciones en cada commit y en cada envío, git bisect para encontrar por búsqueda binaria el commit exacto que introdujo un fallo, git blame para reconstruir la historia de cada línea, los alias y los formatos avanzados de git log para consultar todo eso con comodidad, los submódulos para componer proyectos a partir de varios repositorios, y git worktree para tener varias copias de trabajo del mismo repositorio a la vez.

Empezamos por la automatización, en la lección 06-01: Usando Git Hooks.