Saltar al contenido
Volver a Recursos
GuíaPrincipiante

Guarda todo en GitHub antes de que la IA te rompa el proyecto · tu botón de deshacer infinito

Te ha pasado, o te va a pasar: le pides a la IA un cambio pequeño, ella toca cuarenta archivos, y de repente tu app que funcionaba perfecto ya no abre. No siempre es un desastre —muchas herramientas guardan tu proyecto— pero un comando equivocado, un borrado accidental o un cambio masivo de la IA sí te pueden dejar sin forma de volver. GitHub es tu seguro propio, separado de la herramienta: vuelves al instante exacto en que todo funcionaba, con un clic, sin perder nada. No es solo "para programadores" — es la red que te quita el miedo a dejar que la IA trabaje a fondo. Pero el secreto no es montarlo una vez: es saber EN QUÉ MOMENTO guardar y volverlo un hábito. Eso es lo que de verdad te aprendes aquí.

Jun 18, 202611 min
¿Para quién es esto?
Para cualquiera que construya con IA y aún no use GitHub — o lo use a medias. No necesitas programar. Si alguna vez te dio miedo aceptar un cambio de la IA "no vaya a ser que rompa algo", esta guía te quita ese miedo. Y va más allá del "qué es": te enseña en qué momentos exactos guardar y cómo volverlo un hábito, que es donde casi todos fallan. Hay una vía con botones y una por chat con tu agente: tú eliges.

¿Cuándo surge la necesidad? (el momento exacto)

La necesidad aparece justo cuando empiezas a construir una app de verdad con IA — no cuando solo charlas con ella. En ese punto la IA toca muchos archivos a la vez, y un día le pides un cambio pequeño y, sin querer, rompe tres cosas que funcionaban. Ahí es cuando descubres si tenías una red… o no.

Aclaremos el miedo: accidente, no apocalipsis
Seamos honestos: no es que "se borre todo" siempre. Muchas herramientas guardan tu proyecto en una carpeta o en su nube. El problema real es otro y más silencioso: un comando equivocado, un borrado accidental, o un cambio masivo de la IA que daña lo que servía — y si no tienes un punto al cual volver, ese trabajo se perdió. GitHub es tu seguro aparte, que no depende de qué herramienta uses.

Y hay un segundo freno, más sutil: el miedo a experimentar. Sin red, pides cambios tímidos para no romper nada — y los cambios tímidos no construyen nada grande. Con GitHub guardado, te atreves: si sale mal, vuelves atrás y listo.

Imagínalo así
GitHub es la función "deshacer" de tu editor de texto… pero para tu proyecto entero, y sin límite. En vez de deshacer la última palabra, vuelves al proyecto completo tal como estaba ayer, hace una hora, o justo antes del cambio que lo rompió. Una máquina del tiempo para tu código.

¿Qué es Git y qué es GitHub? (en una frase cada uno)

Git es el sistema que guarda fotos de tu proyecto en el tiempo (cada foto se llama commit). GitHub es la nube donde subes esas fotos para tenerlas a salvo y poder volver a cualquiera. Git vive en tu computador; GitHub vive en internet. Juntos = respaldo + máquina del tiempo.

La analogía del videojuego
Un commit es un punto de guardado, como en un videojuego. Avanzas, guardas. Avanzas, guardas. Si el siguiente nivel sale mal, recargas la última partida y no perdiste todo el progreso. Eso es exactamente lo que haces con GitHub, pero con tu proyecto.

¿Dónde vive tu proyecto? Carpeta local vs sandbox

Esto es clave para entender por qué GitHub te conviene siempre, sin importar con qué construyas. Las herramientas de IA guardan tu proyecto de dos formas, y en ambas GitHub gana:

Carpeta local — herramientas como Claude Code trabajan sobre una carpeta en tu propio computador. Para verla corriendo abres el localhost en tu navegador. El proyecto es tuyo y está en tu disco… pero si lo borras por accidente o un comando lo daña, sin respaldo en la nube no hay vuelta atrás.

Sandbox propio — otras herramientas (como NeuralOS, v0, Bolt y similares) corren tu app dentro de su propio entorno, y tú la ves desplegada ahí mismo, sin manejar carpetas. Comodísimo. Pero tu código vive en la cuenta de esa plataforma — si quieres una copia que sea tuya de verdad y que sobreviva pase lo que pase, la pones en GitHub.

La conclusión que importa
Sea carpeta local o sandbox, GitHub es el único respaldo que es 100% tuyo y no depende de la herramienta. Es tu copia maestra. Por eso vale la pena en los dos casos — y por eso conviene conectarlo justo cuando empiezas a construir una app en serio.

La vía sin terminal · GitHub Desktop (recomendada para empezar)

Si la palabra "terminal" te da pereza, esta es tu vía. GitHub Desktop es la app oficial y gratuita de GitHub: hace todo con botones. Ves la lista de tus cambios, escribes una nota, y guardas — sin un solo comando. Su propio lema lo dice: "concéntrate en lo que importa en vez de pelear con Git".

Arranca en 4 pasos (con botones)
  • Crea una cuenta gratis en github.com (si no tienes).
  • Descarga GitHub Desktop desde desktop.github.com/download (Mac y Windows).
  • Abre tu proyecto en la app: File → Add Local Repository y elige la carpeta.
  • Pulsa Publish repository para subirlo a la nube. Listo: ya está a salvo.

A partir de ahí, cada vez que la app te muestre cambios, escribes una nota corta abajo a la izquierda (el Summary), pulsas Commit to main, y luego Push origin. Eso es un punto de guardado subido a la nube. Hazlo cada vez que algo funcione bien.

GitHub Desktop es oficial y gratis
Es de código abierto, licencia MIT, mantenido por el propio GitHub (más de 21 mil estrellas en su repositorio). No es un truco ni una app de terceros: es la herramienta que GitHub hizo justamente para quien no quiere usar comandos.

La vía con comandos · 4 que valen oro

Si prefieres la terminal (o tu IA la usa por ti), con estos cuatro comandos tienes el 90% de lo que necesitas. Tu IA los conoce de memoria — puedes pedirle que los ejecute y te explique cada uno.

1 · Empezar a rastrear tu proyecto (una sola vez)bash
git init
git add .
git commit -m "primer punto de guardado: el proyecto funciona"
2 · Ver qué cambió (antes de guardar)bash
git status
3 · Guardar un nuevo punto (cada vez que algo funcione)bash
git add .
git commit -m "describe en pocas palabras qué lograste"
4 · Subirlo a la nube (a salvo de verdad)bash
git push
No te aprendas nada de memoria
El mejor truco: deja que tu IA lo haga. Dile "guarda el progreso en git con un mensaje que describa lo que acabamos de lograr y súbelo a GitHub" y ella corre los comandos por ti. Tú solo decides cuándo guardar.

El momento clave · volver atrás cuando la IA rompió algo

Aquí está el superpoder. Imagina que tu app funcionaba, le pediste un cambio, y ahora está rota. Si guardaste un punto cuando funcionaba, recuperarlo es trivial. En GitHub Desktop: menú History, clic derecho sobre el punto bueno → Revert changes. Con comando, tienes dos formas según lo que quieras:

Deshacer un cambio creando uno nuevo que lo anula (seguro)bash
git revert HEAD

Ese git revert es el más seguro: no borra historial, solo crea un punto nuevo que deshace el último. Si solo quieres recuperar un archivo tal como estaba en un punto anterior, le pides a tu IA: "devuélveme el archivo X tal como estaba en el último commit que funcionaba" y ella usará git checkout. La regla de oro:

Pídeselo en español a tu IA
No tienes que recordar si es revert, reset o checkout. Dile: "algo se rompió. Devuélveme el proyecto exactamente como estaba en el último punto que funcionaba, sin perder mi trabajo posterior si es posible." Tu IA elige el comando correcto. GitHub es la red; tu IA es quien la usa.

Ramas · prueba locuras sin miedo (opcional pero mágico)

Una rama es una copia paralela de tu proyecto donde puedes experimentar sin tocar la versión que funciona. ¿Quieres que la IA intente algo arriesgado? Creas una rama, lo prueba ahí, y si sale bien lo unes (merge); si sale mal, la borras y no pasó nada. Tu versión principal nunca corrió peligro.

La analogía del borrador
La rama principal (main) es tu documento en limpio. Una rama nueva es una fotocopia donde haces garabatos. Si los garabatos quedaron bien, los pasas al limpio. Si no, tiras la fotocopia. El original siempre intacto.
Crear una rama para experimentarbash
git checkout -b prueba-arriesgada

Lo más importante · los 5 momentos en que SIEMPRE guardas

Aquí está el verdadero secreto, y es lo que casi nadie hace: GitHub no se monta una vez y ya. Su valor está en el hábito. Si no alimentas GitHub de forma constante, el día que lo necesites no habrá nada a lo cual volver. Estos son los cinco momentos en que guardar no se negocia — los mismos que usamos los que construimos en serio:

Guarda SÍ o SÍ cuando…
  • Algo funciona. Lograste que el botón, la pantalla o el flujo sirva → guarda. Ese es un punto al que querrás volver.
  • ANTES de un cambio grande o arriesgado. Vas a pedirle a la IA algo gordo → guarda primero. Si sale mal, vuelves en un clic.
  • Después de revisar y arreglar bugs. Acabas de auditar y dejar todo limpio → guarda ese estado bueno. (Así trabajamos: auditar, arreglar, y entonces guardar.)
  • Al terminar cada sesión. Te vas a desconectar → sube a la nube. Si tu computador muere, tu proyecto vive.
  • Antes de dejar que la IA "experimente" sola. Le das vía libre para probar → ten el punto de respaldo listo.
La frase que lo resume
El error no es no tener GitHub. El error es no alimentarlo. Vuélvelo un reflejo: "funcionó → guardo", "voy a tocar algo grande → guardo antes". Diez segundos cada vez que valen meses de trabajo.

Guarda limpio · no llenes GitHub de basura

Un buen historial es uno donde cada punto significa algo. Dos reglas simples para que tu GitHub sea útil y no un basurero:

Buenas prácticas para guardar limpio
  • Guarda en momentos limpios (cuando algo funciona o quedó arreglado), no a mitad de un cambio roto.
  • Mensajes que tu yo del futuro entienda: "arreglé el botón de pago", no "cambios" ni "asdf".
  • No subas archivos basura: dependencias (node_modules), temporales ni secretos (.env). Eso va en el .gitignore (lo vemos abajo).
  • Un punto = una idea. Si hiciste tres cosas distintas, está bien guardar tres veces con su nota cada una.

Errores típicos del principiante (y cómo evitarlos)

No subas tus contraseñas a GitHub
Si tu proyecto tiene llaves, contraseñas o tokens en un archivo (suele llamarse .env), nunca deben subir a GitHub. Pídele a tu IA que cree un archivo .gitignore con .env adentro — eso le dice a Git "ignora esto, no lo guardes". Es el error número uno y se evita en 10 segundos.
Repositorio privado por defecto
Al publicar, GitHub te pregunta si el repositorio es público o privado. Si es tu proyecto personal o de negocio, elige privado. Público significa que cualquiera en internet puede ver tu código. Puedes cambiarlo después, pero arranca en privado por seguridad.

El camino más fácil · deja que tu agente lo haga por el chat

Si estás usando un agente de código (como Claude Code), casi todo se hace por el chat — no tienes que aprenderte comandos. Esto es lo que tu agente PUEDE hacer solo por mensaje, y lo poco que te toca a ti:

Quién hace qué
  • Lo hace el agente por chat: crear el .gitignore, el primer punto de guardado, todos los guardados siguientes, subir a la nube y volver atrás si algo se rompe.
  • Lo haces tú una vez (5 min): crear tu cuenta en github.com y, si quieres conectar a mano, crear el repositorio vacío ahí. Algunos agentes incluso esto lo hacen solos si les das permiso.
  • El truco de conexión: crea el repositorio vacío en GitHub, copia su nombre/URL, y pásaselo a tu agente: "conéctame este proyecto a este repositorio y súbelo". Él hace el resto.
¿Cómo nombrar el repositorio?
Sencillo y en minúsculas, con guiones en vez de espacios: mi-tienda-online, app-de-recetas, landing-cafe. Sin tildes ni mayúsculas raras. El nombre solo lo ves tú (y quien invites). Si dudas, ponle el nombre de tu proyecto tal cual.

Prompt listo · pásaselo a tu IA y queda todo configurado

Este es el prompt completo, de principio a fin. Cópialo, reemplaza lo que está entre corchetes, y pégaselo a tu agente de código. Te deja GitHub montado, conectado y con el hábito de recordarte guardar.

Copia esto y pásaselo a tu agente de códigotexto
Quiero proteger mi proyecto con GitHub aunque no sé de git. Guíame paso a paso y hazlo tú donde puedas. Mi proyecto se llama [NOMBRE]; lo construyo con [Claude Code / NeuralOS / otra herramienta].

1) CUENTA: si no tengo cuenta de GitHub, dime exactamente cómo crearla en github.com (gratis) en pasos cortos.

2) REPOSITORIO: dime cómo crear un repositorio NUEVO y PRIVADO. Sugiéreme un nombre en minúsculas con guiones a partir del nombre de mi proyecto. Si puedes crearlo tú con mi permiso, hazlo; si no, dime los clics exactos y yo te paso el nombre o la URL.

3) LIMPIEZA: crea un .gitignore que ignore .env, node_modules, archivos temporales y cualquier secreto, para no subir basura ni contraseñas.

4) PRIMER PUNTO: inicializa git, haz el primer commit con un mensaje claro y conéctalo y súbelo a mi repositorio privado.

5) HÁBITO: de ahora en adelante, cada vez que logremos algo que funcione, ANTES de un cambio grande, y después de revisar/arreglar bugs, recuérdame guardar un punto y pregúntame si lo subimos a la nube. Usa mensajes de commit claros que mi yo del futuro entienda.

6) RESCATE: si algo se rompe, ayúdame a volver al último punto que funcionaba sin perder mi trabajo, y explícame en una frase qué pasó.

Hazlo simple. Si algo solo lo puedo hacer yo por la web, dímelo con los clics exactos.
Pégalo de nuevo cuando quieras
Guarda este prompt. Cada vez que arranques un proyecto nuevo se lo vuelves a pegar al agente y en dos minutos tienes la red de seguridad puesta. Es el mismo gesto, siempre.

La herramienta oficial (gratis y verificada)

desktop/desktopREPO

GitHub Desktop — la app oficial y gratuita de GitHub para usar Git con botones, sin terminal. "Concéntrate en lo que importa en vez de pelear con Git." Descárgala en desktop.github.com/download.

TypeScriptMITVer en GitHub
En NeuralOS no peleas con esto
Dentro de NeuralOS, cada app que construyes guarda su historial de versiones automáticamente — sin que tengas que pensar en commits ni ramas. La red de seguridad viene puesta. Si quieres el poder de GitHub sin la curva de aprendizaje, ese es el camino.
El protocolo C-A-R · construir software sin bugs con tu IAYa que tienes red de seguridad, el siguiente paso: que la IA no te entregue bugs escondidos en primer lugar.
#github#git#respaldo#principiante