Cómo usar GitHub con Claude Code sin entender Git ni memorizar

Git es una de esas cosas que la gente aprende dos veces y olvida tres.

Yo lo he usado durante años y sigo teniendo que mirar cómo se hacía tal cosa cuando me salgo del camino de siempre. No es que sea difícil: es que tiene un vocabulario propio que no se parece a nada, y unos comandos con nombres que no dicen lo que hacen.

La buena noticia es que ya no hace falta memorizarlo. Le hablas en español a Claude Code y él escribe los comandos.

Y la noticia todavía mejor: eso no es hacer trampa. Es exactamente lo mismo que hace un programador que lleva quince años, solo que él tiene los comandos memorizados y tú no. El resultado es idéntico.

¿Necesito aprender Git para trabajar con Claude Code?

No necesitas aprender los comandos. Sí necesitas entender tres ideas, y son tres, no treinta.

Guardar un punto. Cada vez que terminas algo que funciona, dejas una marca. Como guardar la partida antes del jefe final. Eso se llama commit y es lo único que vas a hacer el noventa por ciento del tiempo.

Volver a un punto guardado. Si algo se rompe, vuelves a la última marca. Todo lo que hiciste después desaparece y tu proyecto vuelve a estar como estaba. Esto es la red de seguridad y es el motivo real de usar Git.

Tener una copia fuera de tu ordenador. GitHub es donde vive esa copia. Si tu portátil se cae por las escaleras, tu proyecto sigue existiendo. Y si trabajas desde dos sitios, tienes lo mismo en los dos.

Ya está. Con esas tres ideas ya puedes trabajar. Todo lo demás, ramas, fusiones, conflictos, es maquinaria para equipos grandes y no la necesitas hasta que la necesites, y para entonces se la pides.

Si quieres la explicación desde cero de qué es todo esto y por qué existe, la tengo aparte en qué es un repositorio de Git.

Paso 1: la cuenta y la conexión

Te creas una cuenta en GitHub. Gratis, con tu correo.

Y luego viene la parte que da pereza y que solo se hace una vez: autorizar tu ordenador para que pueda subir cosas sin pedirte la contraseña cada vez.

Aquí es donde le hablas a Claude directamente: "quiero conectar este ordenador con mi cuenta de GitHub para poder subir proyectos. Guíame paso a paso y dime exactamente qué tengo que hacer yo en la web."

Te va a ir llevando. Va a generar lo que haga falta, te va a decir dónde pegarlo en GitHub y te va a comprobar que funciona. Lo que tú haces es copiar, pegar y decir que sí.

Diez minutos, una vez en la vida de ese ordenador.

Paso 2: la frase que usas el noventa por ciento del tiempo

Trabajas en tu proyecto. Consigues que algo funcione. Y dices:

"Guarda este avance en Git con un mensaje descriptivo y súbelo a GitHub."

Eso es todo. Esa frase.

Lo que va a hacer por debajo es mirar qué archivos han cambiado, prepararlos, escribir un mensaje que describa el cambio y subirlo. Cuatro comandos que tú no has escrito.

Y el mensaje que escribe suele ser mejor que el que escribirías tú, porque él sí ha mirado qué cambió exactamente y tú te acuerdas a medias.

Mi regla de cuándo hacerlo: cada vez que algo funcione. No al final del día, no cuando esté "terminado". Cuando una cosa concreta ya va, se guarda. Si guardas cinco veces al día, tienes cinco puntos de retorno. Si guardas una vez a la semana, tienes uno.

Paso 3: volver atrás cuando la líes

Este es el momento en el que Git deja de ser burocracia y pasa a salvarte.

Has estado tocando cosas, algo se ha roto, y no sabes qué fue. La frase:

"Algo se ha roto. Enséñame los últimos puntos guardados y devuélveme al último que funcionaba."

Te va a listar los guardados con su mensaje y su fecha. Eliges. Y vuelves.

Hay una versión más fina que es la que uso más: "compara el estado actual con el último punto guardado y dime qué ha cambiado". Muchas veces no hace falta volver atrás, basta con ver qué se tocó, porque ahí está el fallo delante de tus narices.

Y una tercera, para cuando la cosa está muy fea: "descarta todos los cambios que no estén guardados y déjame como en el último punto". Eso es el botón de pánico. Existe, funciona, y te va a sacar de más de un apuro.

Paso 4: el flujo real de un día

Así trabajo yo, sin abrir la documentación de Git nunca.

Al empezar, si trabajo desde otro ordenador o desde el servidor: "tráete lo último de GitHub antes de empezar". Sin eso, machacas lo que hiciste ayer desde otro sitio, que es el error más doloroso de todos.

Durante el día, cada vez que algo funciona: "guarda esto y súbelo".

Antes de meterme en algo grande o arriesgado: "guarda el estado actual antes de que empecemos con esto". Ese guardado preventivo es lo que me permite luego dejarle trabajar rápido sin revisar cada movimiento.

Y al terminar: "sube todo lo pendiente y dime si me he dejado algo sin guardar".

Cuatro frases. Ninguna tiene un comando dentro. El detalle de cómo encaja esto en un flujo sin tocar la terminal para nada lo tengo desarrollado en mi flujo de Git con Claude sin terminal.

Paso 5: pedir explicaciones mientras trabajas

Esta es la parte que convierte el atajo en aprendizaje de verdad.

Cada cierto tiempo, cuando hace algo, le pregunto: "explícame qué acabas de hacer y por qué, como si no supiera nada de Git".

Y te lo cuenta. En dos párrafos, con tu caso concreto delante, que es infinitamente mejor que cualquier tutorial genérico.

A los dos meses de hacer esto de vez en cuando, resulta que entiendes Git. No porque te sentaras a estudiarlo, sino porque te lo han explicado treinta veces con tus propios ejemplos. Yo he aprendido así cosas que llevaba años usando sin comprender.

Lo que se te va a atascar

Subir archivos que no debías. Claves, contraseñas, archivos de configuración con datos privados. Si eso llega a un repositorio público, está publicado. Y borrarlo después no basta, porque queda en el historial. Antes de subir nada la primera vez: "revisa este proyecto y dime si hay algún archivo con claves o datos privados que no deba subirse, y créame el archivo para ignorarlos".

Público o privado. Al crear el repositorio te lo pregunta. Si dudas, privado. Siempre se puede hacer público después; al revés, lo que se vio ya se vio.

Los archivos grandes. GitHub no quiere vídeos ni bases de datos pesadas. Si te da un error raro al subir, mira si hay un archivo enorme metido. Esos van fuera del repositorio.

Trabajar desde dos sitios sin sincronizar. Empiezas en el portátil, sigues en el ordenador de casa y no trajiste lo último. Ahí sí aparecen los conflictos de verdad. La solución es aburrida: traer siempre antes de empezar. Y si ya has liado el conflicto, se lo pasas tal cual: "tengo un conflicto, explícame qué versión es cuál y ayúdame a resolverlo".

Creer que ya está guardado. Guardar en Git y subir a GitHub son dos cosas. Puedes tener veinte puntos guardados en tu ordenador y cero copias fuera. Por eso mi frase incluye siempre "y súbelo".

Y ahora qué

Coge el proyecto que tengas a medias ahora mismo y dile: "conecta este proyecto con un repositorio privado en GitHub y sube el estado actual".

Eso es todo lo que necesitas para empezar. En diez minutos tienes tu trabajo respaldado fuera de tu ordenador y un punto al que volver.

Y a partir de ahí, la costumbre: cada vez que algo funcione, lo guardas. Es el hábito que más disgustos evita de todos los que puedes coger trabajando con IA, precisamente porque cuando dejas que una IA toque muchos archivos a la vez, tener un punto de retorno deja de ser una buena práctica y pasa a ser la condición para poder ir rápido.

Si estás empezando con la herramienta y esto te queda grande, lo básico de todo está en Claude Code para no programadores.

El flujo completo, desde la instalación hasta tener tu web publicada y respaldada, lo enseño paso a paso sin dar por hecho que sabes programar.

Crea tu web con Claude Code