Git para IA 2, branches y reviews
Branch-per-ask, leer diffs, y por qué nunca debes pedirle a Claude un undo a ciegas.
De qué va esto
La Lección 1 te dio la red de seguridad. Esta lección te lleva al nivel donde te sientes realmente tranquilo trabajando con la IA. Tres cosas: branches como sandbox, leer diffs antes de hacer commit, y por qué nunca deberías dejarle un rollback a ciegas a la IA.
Por qué existen los branches
Imagina que tienes un proyecto que funciona. El login funciona, el pago funciona, todo bien. Ahora quieres que Claude construya una nueva feature, por ejemplo un modo oscuro.
Modo oscuro es un cambio pequeño, piensas. Qué puede salir mal.
En la práctica: Claude toca el sistema de temas, también toca el layout CSS, añade una nueva librería, y de repente la pantalla de login se ve rota. Si hiciste todo esto directamente sobre tu estado principal, ahora tienes dos problemas en lugar de uno.
Los branches resuelven esto. Un branch es una versión paralela de tu proyecto donde puedes probar cosas sin tocar el estado principal.
En la metáfora del save-game: un branch es cuando copias tu partida antes de entrar en el dungeon difícil. Si mueres y no te gusta la copia, la borras. El original queda intacto.
Branch-per-ask, el patrón más importante
La regla es simple. Antes de cada tarea grande de IA, creas un nuevo branch.
En GitHub Desktop, arriba en el centro hay un dropdown de branch. Click, "New branch". Le pones nombre, por ejemplo feature/dark-mode. Click.
Ahora estás en un branch nuevo. Cualquier cosa que tú o la IA hagáis aquí no toca tu estado principal.
Ahora dejas que la IA construya.
Tres resultados posibles:
- Funciona y se ve bien. Commit, vuelve a
main, hace merge del branch. Listo. - Funciona a medias y quieres seguir. Commit en el branch, sigue trabajando, merge más tarde cuando todo encaje.
- Basura. Vuelve a
main, borra el branch, vete a comer.
El resultado 3 es la razón por la que existen los branches. Sin uno, ahora estarías limpiando. Con uno, no perdiste nada.
Leer el diff, la jugada infravalorada
Un diff es la lista de todos los cambios desde el último save state. Qué líneas se añadieron, cuáles se quitaron, en qué archivo.
En GitHub Desktop ves esto automáticamente. Click en un archivo modificado a la izquierda, a la derecha ves línea por línea qué cambió. Verde es nuevo, rojo se fue.
Antes de hacer commit, mira el diff. Un minuto es suficiente.
Buscas tres cosas:
- ¿La IA cambió cosas que tú no pediste? Patrón clásico de Claude y Cursor: pides una función, la IA refactoriza otras tres porque le parecen más bonitas así. El diff te lo enseña.
- ¿Faltan archivos que necesitas? A veces la IA borra código que considera inutilizado pero que se llama desde otro sitio.
- ¿Hay secretos ahí dentro? API keys, contraseñas, contenido de .env. Si haces commit y push de eso a GitHub, queda en internet para siempre, aunque lo borres después. Los diffs lo cazan.
Si el diff se ve limpio, commit. Si no, manda a la IA a corregirlo o descarta los cambios.
Pull requests, incluso trabajando solo
Pull request suena a trabajo de equipo. Pero puedes usarlo en solitario, y vale la pena.
Flujo:
- Estás en un branch (p. ej.
feature/dark-mode), los cambios están dentro. - Push del branch a GitHub (click en GitHub Desktop).
- En github.com ves un banner "compare and pull request". Click.
- Aterrizas en una página que te muestra todo el diff grande y legible.
- Puedes comentar, aprobar, hacer merge.
Lo que sacas: ves los cambios otra vez en una vista completamente distinta. A veces detectas algo en la vista del navegador que se te escapó en el editor. Más un historial bonito en GitHub con descripciones de por qué hiciste qué.
La trampa: Claude y git reset --hard
Ahora un aviso que casi ningún tutorial para principiantes incluye.
Si le dices a Claude Code "¿puedes deshacer eso?", puede pasar que Claude ejecute git reset --hard. Ese es un comando destructivo. Borra todo desde el último commit sin posibilidad de recuperación. Si tenías dos horas de cambios sin commit, se fueron.
Hay un bug report oficial en el repo de claude-code (Issue 17190 de enero de 2026) donde exactamente eso pasó y la persona que lo reportó perdió horas de trabajo.
Qué hacer en su lugar:
- Si quieres volver a un commit anterior, hazlo tú en GitHub Desktop. Click derecho en el commit, "Revert this commit". Ese es el camino seguro, todos los cambios siguen en el historial, el revert mismo es un commit nuevo.
- Si estás dentro de Claude Code y quieres deshacer solo los últimos cambios, usa el comando
/rewind(alias/checkpoint). Es el undo seguro propio de Claude, hace rollback del código Y de la conversación al punto elegido. - Si quieres darle una tarea específica de limpieza a Claude, sé concreto. "Borra los últimos cambios en src/auth.ts y restaura el estado del commit a3b4c5" es mucho más seguro que "deshazlo".
Regla práctica: los rollbacks pasan en la GUI o con /rewind. Nunca como un comando vago a la IA.
Disciplina de commits
Una última cosa. Haz más commits, más cortos.
Los principiantes suelen construir durante una hora y luego hacen un commit gigante "todo hecho". Si algo se rompe después, el commit es tan grande que el rollback borra toda la hora.
Mejor: commit cada 15 a 30 minutos, o cada vez que un pequeño paso esté hecho. Una buena regla para principiantes: commit corto antes de CADA tarea que le des a la IA. Así siempre tienes un save state justo antes del siguiente cambio.
Qué puedes hacer ahora
- Crear branches y aplicar el patrón branch-per-ask
- Leer diffs y reconocer tres problemas típicos de la IA en ellos
- Usar pull requests para trabajo en solitario
- Distinguir comandos de rollback seguros de destructivos
- Encontrar una frecuencia razonable de commits
La Lección 3 te enseña la jugada profesional: el GitHub MCP Server. Con él, Claude Code puede hablar directamente con tu cuenta de GitHub, leer issues, abrir pull requests, depurar fallos de CI.