Revisar con git lo que cambió la IA: del commit previo al diff y al commit final

01No confundir los checkpoints de la IA con git

Claude Code crea checkpoints automáticos con cada prompt y ofrece opciones para restaurar código o conversación mediante `/rewind`, pero la documentación oficial explica que esto no sustituye a un sistema de control de versiones como git. En particular, los archivos modificados por comandos Bash como rm, mv o cp, y los archivos cambiados directamente fuera de Claude Code, pueden quedar fuera del seguimiento o la restauración de los checkpoints. Por eso, en trabajos importantes conviene mantener un punto de referencia con git independientemente de las funciones de la IA.

El objetivo de este artículo no es aprender todas las funciones de git. Usaremos únicamente el flujo mínimo de hacer un commit del estado previo, leer el diff después de los cambios de la IA, comprobar el resultado de ejecución y después hacer el commit final.

02Hacer un commit de referencia antes de delegar el trabajo a la IA

Si ya estás en un repositorio git, revisa primero el estado actual; si todavía no lo es, puedes inicializar el repositorio en la carpeta de práctica. El ejemplo siguiente registra como punto de referencia previo al trabajo los archivos creados hasta el artículo anterior. En un proyecto real, no añadas todos los archivos de forma automática: usa `git status` para comprobar qué se incluirá.

cd vibe-expenses
git init
git status --short
git add expenses.csv summarize.py CLAUDE.md
git diff --cached
git commit -m "Baseline before category summary"

Si es tu primer commit con git en este equipo, `git commit` puede detenerse porque no existe información del autor. En ese caso, configura una vez git config --global user.name "Nombre" y git config --global user.email "correo" y vuelve a hacer el commit. Si vas a publicar el repositorio, usa una dirección de correo que puedas hacer pública.

`git diff --cached` muestra los cambios que ya están en staging y que entrarían en el commit. En el primer commit la salida puede ser larga, pero al menos debes comprobar que no se haya incluido ningún archivo no previsto. En un repositorio de trabajo real, no añadas por descuido archivos sensibles como `.env`, archivos de claves o datos personales. Esta serie usa únicamente datos ficticios desde el principio.

03Encargar una sola función cada vez y limitar los archivos modificados

Este trabajo consiste en una sola función: añadir la opción `--by-category` a summarize.py. Al pedírselo a Claude Code, limita el alcance e indica que no haga al mismo tiempo otras refactorizaciones ni reorganizaciones de archivos. Cuanto más pequeño sea el cambio, más fácil será leer el diff y localizar la causa si aparece un problema.

Añade la opción `--by-category` únicamente a summarize.py.
No cambies el resultado de la ejecución básica y no modifiques expenses.csv ni CLAUDE.md.
No añadas paquetes externos.
Después de modificar, dime qué archivos has cambiado.

La documentación oficial de Claude Code indica que puedes preguntar en lenguaje natural por los archivos modificados, por ejemplo con «what files have I changed?». Sin embargo, no confirmes el alcance del cambio solo con la respuesta de la IA; en el paso siguiente revisa el estado real que muestra git.

04Leer primero git status y git diff personalmente

Cuando termine el trabajo, revisa primero los archivos modificados con `git status --short`. Si se cumplieron los requisitos, solo summarize.py debería aparecer modificado. Después, lee los cambios reales aún no confirmados con `git diff -- summarize.py`. Si miras solo el nombre del archivo y haces commit de inmediato, puedes pasar por alto una línea que la IA haya cambiado incorrectamente.

git status --short
git diff -- summarize.py

• Comprobar que expenses.csv y CLAUDE.md no se hayan modificado de forma inesperada.
• Comprobar que la lógica de salida mensual básica no se haya eliminado ni cambiado de significado.
• Comprobar que la salida adicional se ejecute solo cuando se cumple la condición `--by-category`.
• Comprobar que no se hayan añadido imports de paquetes no solicitados ni código que escriba archivos.
• Si hay un cambio en el diff que no entiendes, preguntar la razón antes de hacer commit.

Aquí, git diff es la evidencia de lo que cambió realmente, mientras que la explicación de la IA es solo una ayuda para interpretar esa evidencia. Si ambas cosas no coinciden, toma como referencia el diff original y los archivos reales.

05Pedir a Claude que explique el diff sin mezclar explicación y cambios

Si no estás familiarizado con los diff, puedes pedir a Claude Code que explique los cambios actuales. En ese momento, no le pidas además nuevas modificaciones: si solicitas primero solo la explicación, la revisión no se mezclará con cambios adicionales.

Lee el git diff actual y explica qué cambió en summarize.py.
1) La parte que mantiene el comportamiento existente
2) La parte añadida para `--by-category`
3) Si existe código que modifique el CSV original
4) Si se usa algún paquete externo nuevo
Resume únicamente estos cuatro puntos. No modifiques más archivos por ahora.

[Ejemplo editorial · no es una respuesta real]
- Se mantiene el cálculo existente de los totales mensuales y la ejecución básica conserva el mismo formato.
- Se añadieron una estructura de acumulación por category y la condición `--by-category`.
- No se añadió código que escriba en el CSV de entrada.
- Se usa solo la biblioteca estándar de Python y no hay paquetes externos nuevos.

El contenido anterior no es el resultado de un diff leído realmente por Claude Code, sino un ejemplo editorial del formato de explicación. En un trabajo real, compara directamente cada explicación con las líneas de `git diff`.

06Hacer staging solo después de comprobar también la ejecución

Aunque el diff parezca correcto, comprobar el funcionamiento es una tarea independiente. Vuelve a ejecutar los dos comandos verificados en el artículo anterior para revisar la salida básica y la salida con opción. Como este artículo se centra en el flujo de git, no repetimos el código Python; mostramos solo los comandos de ejecución suponiendo que se usa el summarize.py ya verificado.

python summarize.py expenses.csv
python summarize.py expenses.csv --by-category

La ejecución básica debe producir 2026-09 = 26600 y 2026-10 = 9800. En la ejecución con opción debes comprobar para 2026-09 food 20500, transport 2900 y supplies 3200. Si los valores no coinciden, no hagas commit: revisa de nuevo el código o el archivo de entrada.

07Revisar por último el staged diff y hacer commit con un mensaje descriptivo

Una vez terminadas la revisión y la comprobación de ejecución, añade al staging solo los archivos modificados que correspondan. Después, usa `git diff --cached` para volver a revisar exactamente lo que entrará en el commit y, solo entonces, haz el commit. Aunque puedes pedir a Claude Code que haga el commit mediante lenguaje natural, para una persona principiante es preferible aprender primero el flujo de verificar personalmente qué archivos se incluirán.

git add summarize.py
git diff --cached -- summarize.py
git commit -m "Add category summary option"
git status --short

La documentación oficial indica que puedes pedir un commit en lenguaje natural, por ejemplo con «commit my changes with a descriptive message». Aun usando esa función, se mantiene el mismo principio: revisar el diff y los archivos objetivo justo antes del commit. Si después del commit `git status --short` no muestra nada, no quedan cambios rastreados pendientes.

Qué comprobar por tu cuenta

Redactado según la explicación sobre git y checkpoints de la documentación oficial de Claude Code, revisada el 2026-09-22 · No se afirma haber ejecutado realmente Claude Code ni los comandos git

• Comprobar que el orden sea coherente: commit de referencia previo → status/diff después del trabajo → comprobación de ejecución → staged diff → commit
• Revisar la sintaxis de `git status --short`, `git diff -- summarize.py`, `git diff --cached -- summarize.py` y `git commit -m`
• Comprobar que se refleje la limitación indicada por la documentación oficial: los checkpoints de Claude Code no sustituyen a git
• Comprobar que se indique que los cambios hechos mediante comandos Bash o fuera de Claude Code pueden quedar fuera de la restauración de checkpoints
• Comprobar que el ejemplo de pedir a Claude una explicación del diff esté marcado como una respuesta no real
• Comprobar que, al no incluir bloques de código Python en el cuerpo del artículo, no haya una ejecución de Python adicional que verificar en este artículo