Cómo usar Git con una app creada con IA

Para usar Git con una app creada con IA, conecta el proyecto a un repositorio de Git, haz un commit después de cada cambio que funcione, escribe un mensaje de una línea que diga qué cambió y mantén los secretos fuera con un .gitignore. Usa una rama para cualquier trabajo arriesgado, haz pull antes de volver a escribir un prompt si alguien más cambió el código y, cuando la IA rompa algo, vuelve al último commit bueno en lugar de seguir escribiendo prompts encima del desastre.

Git es el control de versiones: un historial de cada versión guardada de tu código. GitHub es un sitio web que almacena repositorios de Git en línea. Si estos términos te suenan nuevos, empieza con qué es GitHub. Esta guía trata de los hábitos que hacen útil a Git cuando una IA escribe la mayor parte del código.

Por qué Git importa más con IA

Una IA puede cambiar veinte archivos en un solo turno. Eso es rápido, pero también significa que un prompt puede romper en silencio algo que probaste ayer. Git te da:

• Una forma de volver atrás. Cualquier versión guardada puede restaurarse.
• Un registro de lo que cambió. Puedes ver exactamente qué archivos y líneas tocó un prompt.
• Una copia fuera del creador. Tu código vive en un lugar que tú controlas.
• Un traspaso estándar. Cualquier desarrollador, servicio o herramienta puede trabajar desde un repositorio de Git.

Paso 1: Conecta un repositorio

Crea un repositorio (normalmente privado) en GitHub o en un servicio similar y conecta tu proyecto. La mayoría de los creadores de apps con IA que admiten Git lo hacen desde una página de configuración con un botón “Conectar GitHub”. Si el tuyo no lo tiene, puedes exportar el código y subirlo tú mismo, o pedirle a un desarrollador que lo configure una vez.

Antes del primer push, asegúrate de que el repositorio ignore lo que no debe estar ahí:

Revisa el archivo .gitignore. Asegúrate de que excluya los archivos .env, node_modules, las carpetas de salida de compilación y cualquier archivo que contenga secretos. Dime qué añadiste.

Paso 2: Haz commit después de cada cambio que funcione

Un commit es una copia guardada con un mensaje. El hábito que importa: haz commit cuando algo funcione, antes de pedir la siguiente cosa.

1. Pide un solo cambio.
2. Compruébalo en la vista previa.
3. Si funciona, haz commit (o sincroniza) con un mensaje.
4. Luego sigue con lo siguiente.

Los commits pequeños significan que, cuando algo se rompe, sabes qué cambio lo causó, y deshacerlo no borra otro trabajo.

Paso 3: Escribe mensajes que puedas leer después

Un buen mensaje dice qué cambió y por qué, en una línea:

• Bien: Añade exportación a CSV en la página de pedidos
• Bien: Corrige el formulario de reservas que rechazaba horas después de las 18:00
• No sirve: actualizar, cambios, arreglar cosas

Puedes pedirle a la IA que los escriba:

Resume en una línea los cambios desde el último commit, empezando con un verbo y en menos de 70 caracteres.

Paso 4: Usa ramas para el trabajo arriesgado

Una rama es una línea de trabajo separada. Puedes probar algo en una rama y, si no funciona, abandonarla sin tocar la versión principal.

Usa una rama cuando:

• El cambio es grande (un rediseño, un nuevo flujo de pago, un cambio en la base de datos).
• Otra persona está trabajando en la misma app.
• Quieres que alguien revise el cambio antes de publicarlo.

Cuando el trabajo está terminado y probado, se fusiona (merge) de vuelta a la rama principal. En GitHub, eso suele hacerse mediante un pull request, una página que muestra los cambios para revisarlos. Si tu creador solo sincroniza una rama, un desarrollador puede gestionar las ramas desde GitHub.

Paso 5: Deshaz los cambios con seguridad

Cuando un prompt rompe la app, resiste la tentación de escribir cinco prompts más encima. Vuelve a la última versión buena e intenta con un prompt más claro.

• En el creador: usa su función de punto de restauración, si tiene una.
• En Git: git revert crea un nuevo commit que deshace uno anterior, manteniendo el historial intacto. Es la opción segura para código que otras personas puedan haber traído con pull.
• Evita git push --force en una rama compartida, salvo que sepas exactamente por qué. Reescribe el historial para todos.

Si no estás seguro, pregunta:

El último cambio rompió la página de inicio de sesión. Muéstrame qué archivos cambió comparado con el commit anterior y explica qué hizo cada cambio. No cambies nada todavía.

Paso 6: Haz pull antes de escribir un prompt

Si un desarrollador u otra herramienta cambia el código en GitHub, el creador con IA no lo sabe hasta que traes esos cambios con pull. Escribir prompts sobre código desactualizado provoca conflictos y pérdida de trabajo.

• Haz pull al inicio de cada sesión.
• Acordad quién edita qué, y evita que las dos partes editen los mismos archivos a la vez.
• Si aparece un conflicto de fusión (dos cambios sobre las mismas líneas), pide al desarrollador o a la IA que lo resuelva y que explique la decisión.

Ejemplos de prompts

Antes de empezar: ¿qué cambió en el repositorio desde mi última sesión? Resume los commits.

Haz el siguiente cambio por separado: añade un botón “Duplicar” a cada factura. No cambies nada más, para que pueda hacer commit de este cambio por separado.

Comprueba que no haya claves de API, contraseñas ni archivos .env rastreados en Git, incluidos los commits anteriores. Informa solo los nombres de los archivos, no los valores.

Errores comunes

• Subir secretos. Una vez que una clave está en el historial de Git, queda expuesta, aunque luego borres el archivo. Cámbiala.
• Un único commit gigante por semana. No puedes deshacer un cambio sin deshacer todos los demás.
• Mensajes como “actualizar”. El historial deja de servir para encontrar qué se rompió.
• Escribir prompts sobre código desactualizado. Haz pull primero si alguien más está editando.
• Forzar un push para corregir un error. Puede borrar el trabajo de otras personas. Mejor revierte.
• Subir node_modules. Es enorme y de todos modos se recrea a partir del archivo de bloqueo.

Lista de verificación

• El proyecto está conectado a un repositorio privado.
• .gitignore excluye .env, node_modules, la salida de compilación y los secretos.
• Hago commit después de cada cambio que funciona.
• Los mensajes de commit dicen qué cambió en una línea.
• Los cambios grandes o arriesgados van en una rama y se revisan.
• Hago pull antes de escribir prompts cuando alguien más edita el código.
• Deshago con puntos de restauración o con git revert, nunca con force-push.
• Cualquier clave que alguna vez se subió ha sido cambiada.

Git en Mythex

Mythex guarda un punto de restauración de Git después de cada turno exitoso del agente, y Volver a este punto devuelve el proyecto a ese estado: la forma de deshacer del lado del creador que describe el paso 5. Consulta Itera sin reconstruir.

En Pro, la sincronización con GitHub conecta un repositorio desde la configuración del proyecto para que puedas hacer push y pull, y la exportación descarga el proyecto sin secretos ni node_modules. Consulta GitHub, exportación e importación. Conectar GitHub antes de entregar un proyecto a un desarrollador simplifica mucho el traspaso; consulta cómo trabajar con un desarrollador en una app creada con IA y cómo exportar y alojar por tu cuenta una app creada con IA.

Preguntas