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é ha cambiado y mantén los secretos fuera con un .gitignore. Usa una rama para cualquier cosa arriesgada, haz pull antes de volver a escribir un prompt si otra persona ha cambiado el código y, cuando la IA rompa algo, vuelve al último commit que funcionaba en lugar de seguir escribiendo prompts sobre el desastre.

Git es un 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 conceptos son nuevos, empieza por 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 ofrece:

• Una forma de volver atrás. Cualquier versión confirmada 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.
• Una entrega estándar. Cualquier desarrollador, servicio de alojamiento o herramienta puede trabajar a partir de 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 a él. La mayoría de los creadores de apps con IA que admiten Git lo hacen desde una página de ajustes con un botón de «Conectar GitHub». Si el tuyo no lo tiene, puedes exportar el código y subirlo tú mismo, o pedir a un desarrollador que lo configure una vez.

Antes del primer push, asegúrate de que el repositorio ignora lo que no debería estar ahí:

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

Paso 2: Haz un 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 lo siguiente.

1. Escribe un prompt para un solo cambio.
2. Compruébalo en la vista previa.
3. Si funciona, haz commit (o sincroniza) con un mensaje.
4. Y luego continúa.

Los commits pequeños significan que, cuando algo se rompa, sabes qué cambio lo causó y deshacerlo no tira a la basura otro trabajo.

Paso 3: Escribe mensajes que puedas leer más tarde

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

• Bien: Añade la exportación a CSV en la página de pedidos
• Bien: Corrige el formulario de reservas que rechazaba las horas después de las 18:00
• Poco útil: actualizar, cambios, arreglos varios

Puedes pedirle a la IA que los escriba:

Resume los cambios desde el último commit en una línea, empezando por un verbo, con 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 sale bien, abandonarla sin tocar la versión principal.

Usa una rama cuando:

• El cambio es grande (un rediseño, un nuevo flujo de pagos, 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 nuevo en 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 que funcionaba e intenta un prompt más claro.

• En el creador: usa su función de punto de control o de restaurar, si la tiene.
• En Git: git revert crea un commit nuevo que deshace uno antiguo, 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 ha roto la página de inicio de sesión. Muéstrame qué archivos cambió en comparación 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 de IA no lo sabe hasta que traes (pull) esos cambios. Escribir prompts sobre código antiguo provoca conflictos y pérdida de trabajo.

• Haz pull al inicio de cada sesión.
• Acordad quién edita qué, y evita que los dos lados editen los mismos archivos a la vez.
• Si aparece un conflicto de fusión (dos cambios en 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é ha cambiado 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 él por separado.

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

Errores comunes

• Subir secretos. Una vez que una clave está en el historial de Git queda expuesta, aunque borres el archivo. Cámbiala.
• Un commit gigante a la semana. No puedes deshacer un cambio sin deshacerlos todos.
• Mensajes como «actualizar». El historial deja de servir para encontrar qué se rompió.
• Escribir prompts sobre código desactualizado. Haz pull primero si otra persona está editando.
• Forzar el push para corregir un error. Puede borrar el trabajo de otras personas. Revierte en su lugar.
• Subir node_modules. Es enorme y se vuelve a generar a partir del archivo de bloqueo de todos modos.

Lista de comprobación

• El proyecto está conectado a un repositorio privado.
• .gitignore excluye .env, node_modules, la salida de la 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 un prompt cuando otra persona edita el código.
• Deshago los cambios con puntos de control o con git revert, nunca con force push.
• Cualquier clave que se haya subido alguna vez ha sido cambiada.

Git en Mythex

Mythex guarda un punto de control de Git después de cada turno exitoso del agente, y Revertir a este punto devuelve el proyecto a ese estado: es el deshacer del lado del creador que describe el paso 5. Consulta Iterar sin reconstruir.

En Pro, la sincronización con GitHub conecta un repositorio desde los ajustes del proyecto para que puedas hacer push y pull contra él, y exportar descarga el proyecto sin los secretos ni node_modules. Consulta GitHub, exportación e importación. Conectar GitHub antes de entregar un proyecto a un desarrollador simplifica mucho la entrega: 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