Cómo dejar que Claude gestione Git sin romper tu código

Llevo meses sin tocar Git. No es que se me haya olvidado cómo funciona. Es que ya no lo necesito para casi nada, porque lo gestiona Claude por mí.

Te dejo el vídeo arriba, pero aquí lo tienes escrito y con calma. Va de una idea que mucha gente no está pillando: cómo dejar que la IA lleve el control de versiones ella sola, y por qué eso hace que deje de romperte el código.

Antes de nada, un aviso. Esto no es una verdad universal. Que yo lo haga así no significa que tú debas hacerlo así, porque depende muchísimo del proyecto. Te cuento cómo lo uso yo, y tú lo adaptas a lo tuyo.

Por qué Git ya no es para mí, es para Claude

Git es un control de versiones. Lo básico que todo el mundo conoce: puedes volver a versiones anteriores cuando algo se rompe. Pero eso es lo de menos.

Lo potente de Git es que te deja un registro perfecto de qué cambios se han hecho, dónde, por qué, cuándo y cómo. Un log limpio de todo lo que ha pasado dentro de un sistema.

Y ahí está el giro. Ese registro ya no lo necesito yo. Lo necesita Claude.

Sí, me viene bien tener el control de versiones para llevarme el proyecto a otro ordenador, seguir trabajando desde otro sitio o meter a alguien que me ayude. Pero en el día a día, todo lo que hago en Git es para que Claude sepa qué ha hecho, dónde, cuándo, cómo y por qué.

Por eso dejo que sea él quien gestione Git entero. Él decide qué commits hacer, cómo llamarlos, cuándo. Yo no me meto en cómo lo usa. No es para mí, es para él.

¿Esto vale para cualquier tipo de proyecto?

No. Y aquí está el matiz que la gente se salta.

No es lo mismo un proyecto empresarial enorme, donde depende todo de que Git esté bien gestionado, con muchísimas personas tocando cosas y pull requests por todos lados, que un caso como el mío.

Yo tengo un repo de documentación desde el que gestiono otros proyectos que no afectan a tanta gente ni son tan críticos. Cada caso es un mundo y hay que analizarlo. En proyectos grandes y compartidos, esto que te cuento no aplica igual.

Si tu proyecto se parece más al mío que a una empresa con veinte programadores, sigue leyendo.

El planificador: un solo sitio desde el que trabajo todo

Tengo un proyecto que llamo mi planificador. Es el lugar desde el que gestiono absolutamente todo.

Da igual los proyectos que tenga o los repos que tenga. Mi web, por ejemplo, vive en otro repo distinto, pero desde el planificador la tengo documentada y preparada con mis skills para poder trabajar en ella.

O sea: por un lado, el repo de documentación. Por otro, el repo del código. Y esto se aplica a cualquier proyecto que meto dentro.

El planificador es el sitio desde el que trabajo con Claude para hacer cualquier cosa: negocio, contenido, vida personal, lo que sea. Lanzo una skill para trabajar en un proyecto concreto, y esa skill ya sabe en qué repos tiene que tocar y cómo. Si necesita algo de otro repo, le pide ayuda a la skill que corresponda.

Lo tengo todo en un mismo sitio, y siempre trabajo con Claude desde ahí.

La carpeta de infraestructura, donde vive toda la documentación

Cuando tienes este tipo de montaje, lo que hago es tener una carpeta llamada infraestructura. Es el lugar donde se documenta exactamente todo lo que se hace dentro de cada proyecto.

Un ejemplo con mi web. Dentro de infraestructura tengo varios archivos Markdown, cada uno documentando una funcionalidad concreta. El del SEO, por ejemplo, recoge absolutamente todo sobre cómo está montado el SEO: qué se ha hecho, cómo, qué archivos y bases de datos están involucrados. Todo.

Aquí está lo bueno. En el momento en que tengo que hacer un cambio o una funcionalidad nueva que afecta a eso, lo primero que hace Claude es venirse a leer esa documentación. Necesita entender cómo funciona todo antes de tocar nada.

Imagina que hubo un problema con un deploy de hace tres días relacionado con el SEO. Claude se viene aquí, mira cómo funciona esa parte y qué hay ya preparado, para no repetir código y arrancar con una base clara de qué archivos y qué bases de datos entran en juego. Y sabiendo eso, ya se va a Git y busca los commits donde se tocó exactamente eso.

Es lo que hace cualquier programador. La diferencia es la documentación previa.

¿Por qué Claude deja de romperte el código con esto?

Porque sin esta base pasa lo que a mucha gente le está pasando: Claude va a Git, encuentra un commit que no era el correcto y empieza a tocar cosas sobre la pieza equivocada.

Con la documentación delante, eso no ocurre. La gestión de errores se reduce muchísimo:

• Cero duplicidad de código. No se pone a crear soluciones encima de soluciones que ya existían. Busca la solución que ya hay y la edita, la mejora o la modifica.
• Sabe a qué está afectando cada cambio que hace, porque entiende la funcionalidad completa antes de meter mano.
• Encuentra el commit correcto, no uno cualquiera, porque parte de saber qué archivos están implicados.

Y el detalle importante: esa documentación no la escribo yo. La escribe el propio Claude. Lo tengo puesto en el CLAUDE.md y en las skills: cada vez que se hace algo, hay que documentarlo, en el sitio correcto y al milímetro.

Se apunta hasta cosas pequeñas. El tracking por plataformas de los redirects, por ejemplo, con TK para TikTok, IG para Instagram, YT para YouTube. O notas del tipo "los posts con fecha futura ya no devuelven 404", con el commit donde lo arregló, para saber exactamente cómo quedó esa funcionalidad.

Nada de esto lo podría tener si la documentación viviera solo dentro del código, como hace mucha gente, o si no existiera este repo de documentación separado.

Las herramientas que salen en el vídeo

• Claude Code: la IA que gestiona mi Git y con la que trabajo desde el planificador.
• Gemini CLI y Codex: otras herramientas del mismo estilo, agentes que trabajan desde la terminal.
• Git: el control de versiones de toda la vida, que aquí uso como registro para que la IA entienda qué ha pasado.

Esto no es descubrirte el fuego. Es algo bastante normal para quien ya lleva tiempo. Pero he visto a mucha gente a la que Claude, Codex o lo que sea no les termina de funcionar, y casi siempre es por lo mismo: no tienen esta base de documentación montada. Si ya lo haces así o mejor, este post no era para ti. Si no lo intuías siquiera, ojalá te ahorre unos cuantos destrozos.

Si quieres profundizar, tengo una guía completa de Claude Code para no programadores y un post sobre cómo usar GitHub con Claude sin entender Git que encaja justo con esto. Y si el tema es la documentación en sí, te interesa Claude Code para documentos y notas.

Todo esto que te cuento, el planificador, la carpeta de infraestructura, las skills, la memoria persistente, es lo que enseño a montar en mi formación Yo S.A.. No va de crear una web, va de trabajar con la IA y tu documentación para gestionar todos tus proyectos, los de trabajo y los de tu vida.