Cómo uso Git con Claude sin abrir la terminal (ni una vez)

Llevo meses sin escribir git commit a mano.

Ni git push, ni git pull, ni mirar el log en la terminal. Nada.

Y no porque haya dejado de usar Git. Lo uso más que nunca. Pero ya no soy yo quien lo toca. Es Claude. Y para mucha gente esto va a sonar a "cómo que Claude usa Git por ti", pero es que es exactamente eso. Le hablo en lenguaje natural, le digo lo que quiero, y él ejecuta los comandos. Como si tuviera un becario que no se cansa y no olvida nada.

¿Pero para qué querrías usar Git sin terminal?

Hay dos tipos de persona leyendo esto.

Por un lado, programadores que llevan años viviendo en la terminal y les parece una barbaridad no teclear git status treinta veces al día. Para ellos esto suena a herejía. Lo entiendo. Yo también fui así.

Por el otro, gente que no es programador pero que ha empezado a usar Claude Code o Cursor para montar su web, su sistema de notas, su lo-que-sea. Y a quien alguien en algún momento le ha dicho "oye, usa Git para no perder tu trabajo". Y se han topado con una pared.

Git, para quien no lo ha visto nunca, es como ese amigo muy útil pero que cuando te lo presentan parece un capullo. Terminal, comandos raros, HEAD, rebase, cherry-pick. Madre del amor hermoso. Lo normal es abrirlo, verlo, y volver a tu carpeta "Documentos/proyecto-final-definitivo-v27-bueno".

Pues hoy no hace falta pasar por ahí. Git sigue existiendo por debajo. Pero tú ya no hablas con él. Hablas con Claude. Y Claude habla con Git.

¿Por qué Git ya no es para mí (sino para Claude)?

Esta es la parte que me cambió la cabeza.

Durante años asumí que Git era una herramienta para programadores. Tú, humano, con tu teclado, escribiendo comandos para gestionar versiones de tu código. La terminal abierta, los mensajes de commit, el git log --oneline --graph para sentirte hacker. Todo ese ritual.

Ahora mismo Git sigue siendo una herramienta crítica. Pero el usuario de Git en mi flujo ya no soy yo. Es Claude.

Yo no necesito saber en qué commit está cada cambio. No necesito acordarme de si he mergeado la rama feature/emails o si hice rebase o si me dejé algo sin pushear. Claude lo sabe. Claude lee el historial antes de hacer nada. Claude sabe dónde está, qué hay pendiente, y qué tiene que tocar. Y lo que yo hago es pedirle cosas.

"Claude, añade esto al blog y súbelo." "Claude, haz un commit de lo que hay pendiente con un mensaje que explique lo que hemos cambiado." "Claude, mira qué se tocó hace tres días en el tema de los emails, que creo que ahí hay un bug."

Y él solito se va al repo, mira, hace, commitea, pushea. Si hay algo raro, me lo dice. Si tiene dudas, me pregunta. Y si la cago yo (porque al final la caga uno, no Claude), el historial de Git sigue ahí para volver atrás.

O sea, Git no ha desaparecido. Lo que ha desaparecido es mi relación directa con él.

¿Cómo se monta un flujo así sin que sea un caos?

La clave está en algo que para mí es la piedra angular de todo esto: la documentación.

Yo tengo lo que llamo el planificador. Es mi repo central, desde el que gestiono absolutamente todo. Mi código no vive aquí. Mi web está en otro repo, mis herramientas en otro. Pero desde el planificador tengo documentado cómo funciona cada uno, qué hay en cada sitio, qué decisiones se han tomado.

Y tengo una carpeta que se llama INFRAESTRUCTURA. Un archivo por cada funcionalidad crítica de cada proyecto. SEO, emails, login, foros, lo que sea. Todo documentado al milímetro. Y no lo escribo yo. Lo escribe Claude mientras trabajamos. Porque dentro de mi CLAUDE.md hay una regla muy clara: cada cambio importante se documenta. Qué archivo se tocó, qué decisión se tomó, qué commit quedó pendiente.

Resultado: cuando yo le digo "oye, hay un problema con el deploy del SEO", Claude se va primero a esa documentación. Lee cómo está montado. Ve qué archivos están implicados. Mira qué commits se hicieron recientemente. Y con todo ese contexto entra a trabajar. No toca por tocar. No duplica código.

Esta parte es la que mucha gente se salta y por eso a mucha gente Claude Code no le termina de funcionar. No es que la herramienta falle. Es que llega sin mapa. Y sin mapa, da igual lo bueno que sea Claude, va a tocar sobre el commit equivocado.

¿Y qué pasa si no eres programador y todo esto te suena a chino?

Buenas noticias.

No necesitas entender Git. No necesitas saber qué es un commit, una rama o un merge. Claude lo gestiona. Lo único que necesitas es:

Uno. Tener tu proyecto en un repo (Claude te lo crea si se lo pides).

Dos. Tener un archivo de contexto claro. Puede ser un README.md, un CLAUDE.md, da igual el nombre. Un sitio donde le expliques a Claude qué estás haciendo, cómo quieres trabajar, qué hay en cada carpeta.

Tres. Acostumbrarte a pedirle las cosas en lenguaje normal.

"Guarda los cambios de hoy con un mensaje que diga X." "Mira qué se modificó la semana pasada en tal cosa." "Crea una rama nueva para probar una idea sin romper lo que ya funciona."

Y ya. Él traduce eso a comandos. Él los ejecuta. Él te avisa si hay conflicto, si hay algo raro, si necesita que confirmes. Tú haces de jefe, no de ingeniero.

Esto es exactamente lo que hago yo. Y soy programador. Llevo años con Git. Podría hacerlo a mano. Pero es que no compensa. Es más rápido, más limpio, y genera menos errores dejar que lo haga Claude mientras yo voy a lo mío. Que al final, lo mío no es el control de versiones. Lo mío es pensar qué funcionalidad tiene que existir, qué problema estoy resolviendo, qué quiero que pase.

Lo que nadie te cuenta (y es lo más importante)

Hay un detalle aquí que si no lo pillas, esto no funciona.

Git sin Claude funciona bien. Claude sin Git funciona bien. Pero la combinación solo funciona de verdad si tienes contexto bien preparado. Documentación viva. Archivos que se actualizan solos mientras trabajas. Un mapa mental del proyecto que está escrito en algún sitio y no solo en tu cabeza.

Porque Claude es bueno, pero no es mago. Si entra a un repo sin documentación y le pides que arregle un bug, va a tocar cosas. A lo mejor las correctas. A lo mejor no. Va a adivinar. Y Claude adivinando es exactamente lo contrario a lo que tú quieres. Tú quieres Claude ejecutando sobre contexto real, no Claude inventando.

Por eso para mí la fórmula es: Contexto > Prompts. No hace falta escribirle prompts épicos a Claude. Hace falta darle contexto completo del proyecto. Y eso, paradójicamente, lo escribes una vez (con su ayuda) y luego se autoactualiza en cada sesión de trabajo.

Es un poco lo mismo que cualquier buen programador hace cuando entra a un proyecto nuevo: leerse la documentación, mirar los commits recientes, entender cómo está montado antes de tocar. Solo que Claude lo hace en cuatro segundos y sin quejarse. Y tú, cada vez que le pides algo, te ahorras ese paso mental.

El efecto en tu día a día cuando funciona

Cuando esto está bien montado, tu relación con el código cambia.

Dejas de tener miedo a tocar. Cada cambio está versionado, cada paso documentado. Si algo se rompe, no hay drama. Vuelves a un commit anterior con una frase: "Claude, revierte al estado de ayer antes de la última comida". Y ya.

Dejas de dudar de si lo hiciste bien. El historial es claro. Los commits tienen mensajes humanos, no wip y asdf como solía poner yo.

Y lo más importante: dejas de asociar "programar" con "sufrir con la terminal". Que para alguien con un cerebro disperso como el mío es la diferencia entre acabar los proyectos o dejarlos muertos al 40%.

El problema no era Git. Era el interfaz entre Git y yo. Cambié el interfaz. Y ahora Git trabaja para mí en vez de contra mí.

Si quieres ver exactamente cómo tengo montado todo este flujo (no el código, sino la arquitectura de documentación y contexto que hace posible que Claude trabaje así), te dejo mi setup completo aquí.

Ver mi setup de Claude Code