Ramas, reset y revert: cómo experimentar con IA sin miedo a romper tu proyecto

En la primera parte de esta guía vimos qué es Git, por qué es tu red de seguridad cuando programas con IA y el flujo básico: status, diff, add y commit.

Ahora vamos con los dos superpoderes que de verdad te quitan el miedo a experimentar:

1. Las ramas: para probar cosas sin arriesgar lo que ya funciona.
2. Deshacer errores: para volver atrás cuando la IA (o tú) rompe algo.

Dos comandos me han salvado el pellejo más veces de las que me gustaría admitir: git reset y git revert. Al final de este artículo vas a saber exactamente cuándo usar cada uno.

---

¿Qué es una rama?

Una rama es una línea de trabajo paralela de tu proyecto. Imagina que tu código principal (main) es la versión que funciona y que está en producción. Cuando quieres probar algo nuevo, abres una rama: una copia independiente donde puedes hacer lo que quieras sin afectar a main.

Si el experimento sale bien, lo unes (merge) a main. Si sale mal, borras la rama y aquí no pasó nada.

gitGraph
    commit id: "inicio"
    commit id: "login"
    branch experimento-ia
    checkout experimento-ia
    commit id: "IA: nuevo menú"
    commit id: "IA: ajustes"
    checkout main
    commit id: "fix: correo"
    merge experimento-ia id: "merge del menú"
    commit id: "deploy"

En el diagrama, main sigue su camino (hasta se le hace un arreglo) mientras en experimento-ia la IA prueba un menú nuevo. Cuando el menú funciona, se une a main.

Por qué las ramas son perfectas para trabajar con IA

Cada vez que le vas a pedir a un agente algo grande o arriesgado (“migra todo a TypeScript”, “cambia la librería de gráficos”, “refactoriza el módulo de pagos”), hazlo en una rama. Si el resultado no te convence, ni siquiera tienes que deshacer nada: cambias a main y borras la rama.

---

Los comandos de ramas que vas a usar

Qué quieres hacer	Comando
Ver las ramas (la actual tiene un *)	git branch
Crear una rama y cambiarte a ella	git switch -c nombre-rama
Cambiarte a una rama que ya existe	git switch nombre-rama
Unir una rama a la rama en la que estás	git merge nombre-rama
Borrar una rama ya unida	git branch -d nombre-rama
Borrar una rama que no se unió (descartar el experimento)	git branch -D nombre-rama

Si has visto tutoriales viejos, seguro te encontraste git checkout -b. Funciona igual, pero git switch (disponible desde Git 2.23) es más claro porque solo sirve para cambiar de rama, mientras que checkout hace demasiadas cosas distintas.

El flujo completo, paso a paso

# 1. Desde main, crea una rama para el experimento
git switch -c feature/menu-nuevo

# 2. Trabaja (tú o la IA) y guarda los cambios
git add .
git commit -m "feat: rediseñar menú de navegación"

# 3. ¿Funcionó? Vuelve a main y une los cambios
git switch main
git merge feature/menu-nuevo

# 4. Borra la rama, ya no la necesitas
git branch -d feature/menu-nuevo

¿No funcionó? Entonces el paso 3 es solo git switch main y el 4 es git branch -D feature/menu-nuevo. Experimento descartado, proyecto intacto.

Ponle nombres que digan algo

❌ Evita	✅ Mejor
pruebas, pruebas2, pruebas3	feature/login-con-google
cambios-final	fix/menu-movil-se-corta
feature1_v2_fix_final	experimento/migracion-typescript

---

Cuando dos cambios chocan: conflictos de merge

Tarde o temprano te va a pasar: en main y en tu rama se modificó la misma línea del mismo archivo. Git no puede adivinar cuál versión es la correcta, así que se detiene y te pregunta. Eso es un conflicto, y no es un error: es Git siendo prudente.

El archivo queda marcado así:

<<<<<<< HEAD
const titulo = "Bienvenido";
=======
const titulo = "Hola de nuevo";
>>>>>>> feature/menu-nuevo

• Lo que está entre <<<<<<< HEAD y ======= es la versión de la rama donde estás (main).
• Lo que está entre ======= y >>>>>>> es la versión de la rama que estás uniendo.

Para resolverlo: edita el archivo, deja la versión correcta (o una combinación), borra las marcas y guarda:

git add archivo.js
git commit

Editores como VS Code te muestran botones para elegir una versión u otra. Y sí, también puedes pedirle a la IA que te ayude, pero lee lo que propone: decidir cuál cambio es el correcto requiere entender qué hace cada uno.

---

Deshacer errores: el mapa completo

Git tiene varias formas de deshacer y cada una sirve para un momento distinto. Esta tabla es el resumen que me hubiera gustado tener cuando empecé:

Tabla 3: Cómo deshacer cambios según tu situación

¿Qué te pasó?	Comando	¿Pierdes algo?
Cambiaste un archivo y quieres dejarlo como en el último commit	git restore archivo.js	⚠️ Sí, los cambios no guardados
Hiciste git add de algo que no querías	git restore --staged archivo.js	No
Te equivocaste en el mensaje del último commit (y no lo has compartido)	git commit --amend -m "nuevo mensaje"	No
Quieres deshacer commits que solo están en tu máquina	git reset	Depende del modo
Quieres deshacer un commit que ya compartiste	git revert <hash>	No, queda en el historial
Hiciste un reset --hard y te arrepentiste	git reflog	Los commits sí se recuperan

Los dos protagonistas, en corto:

• git reset es la máquina del tiempo: mueve tu rama a un commit anterior como si los posteriores nunca hubieran existido. --soft conserva los cambios preparados, --mixed (el modo por defecto) los deja sin preparar y --hard los borra. Ejemplo: git reset --soft HEAD~1 deshace el último commit. Úsalo solo en commits que no has compartido.
• git revert respeta el pasado: en vez de borrar el commit problemático, crea uno nuevo que hace exactamente lo contrario (git revert 7be0d14). Es el que debes usar cuando el commit ya está en GitHub, en main o en producción. Sé humano al escribir su mensaje: “Revierte los pagos: causaban cobros dobles en producción.”
• git reflog es tu última esperanza: guarda los movimientos de tu rama, así que un reset --hard que borró commits se puede deshacer. Ojo: los cambios que nunca guardaste con commit no se recuperan.

Cada uno tiene más matices (rangos, merges con -m, qué se recupera y qué no, --force-with-lease), y los probé todos en Git reset vs git revert: cuál usar y cómo deshacer sin miedo.

---

Práctica guiada: rompe cosas a propósito

La mejor forma de perderle el miedo a Git es romper algo en un proyecto de prueba. Abre una terminal:

# Prepara un repositorio de juguete
mkdir practica-git && cd practica-git
git init
echo "versión buena" > app.txt
git add . && git commit -m "feat: versión inicial"

# Ejercicio 1: revert
echo "código con bug" >> app.txt
git commit -am "feat: cambio con bug"
git revert HEAD --no-edit         # anula el último commit
cat app.txt                       # vuelve a decir "versión buena"
git log --oneline                 # el bug y su revert quedan en la historia

# Ejercicio 2: reset + reflog
echo "experimento" > prueba.txt
git add . && git commit -m "feat: experimento"
git reset --hard HEAD~1           # el experimento desaparece
git reflog                        # ...pero aquí sigue
git reset --hard HEAD@{1}         # y lo recuperas

Hazlo una vez y nunca más vas a sentir pánico frente a la terminal.

---

Bonus: varios agentes trabajando al tiempo con worktrees

Si ya estás en un nivel donde pones a dos agentes de IA a trabajar en paralelo, hay un problema: los dos estarían editando la misma carpeta. Para eso existe git worktree, que crea una segunda carpeta de trabajo conectada al mismo repositorio, cada una en su propia rama:

git worktree add ../mi-proyecto-pagos -b feature/pagos

Ahora tienes mi-proyecto (en main) y mi-proyecto-pagos (en feature/pagos). Un agente trabaja en cada carpeta sin pisarse. Cuando terminas, unes la rama como siempre y eliminas la carpeta extra con git worktree remove ../mi-proyecto-pagos.

---

En resumen

• Una rama por experimento. Si sale bien, merge; si sale mal, git branch -D y listo.
• Los conflictos no son errores: son Git pidiéndote que decidas.
• restore para cambios sin guardar, reset para commits locales, revert para commits compartidos y reflog para cuando todo lo demás falla.
• Commits pequeños y frecuentes son la mejor póliza de seguro.

Es la misma lógica de trabajar en unidades pequeñas y verificables que defendí en desarrollo modular con IA. Y algo más: antes de pedirle a la IA que “reescriba todo desde cero” en una rama, recuerda la lección de Netscape que conté en La IA abarató el conocimiento, no el criterio. Que algo se pueda deshacer con un comando no significa que sea buena idea hacerlo.

Git no es solo una herramienta técnica: también es una herramienta para pensar. Aprende a equivocarte y a revertir con clase.

---

Fuentes y lecturas recomendadas

• Pro Git (libro oficial, gratuito y en español): capítulo de ramificaciones y el resto del libro.
• Guía completa de reset y revert: Git reset vs git revert: cuál usar y cómo deshacer sin miedo.
• Documentación oficial de Git: git branch, git switch, git merge, git reset, git revert, git reflog y git worktree.
• GitHub Docs: Resolver un conflicto de fusión mediante la línea de comandos.
• Artículos relacionados en este blog:
  • Vibe coding sin Git es manejar sin frenos: qué es un control de versiones
  • Instalar 40 skills no te hace programador: desarrollo modular con IA
  • La IA abarató el conocimiento, no el criterio