¿La sincronización de Lovable con GitHub no funciona?
Por qué tus commits no aparecen en Lovable, qué significan 'diverged' y la rama lovable-sync, y cómo trabajar con GitHub y Lovable sin perder cambios.
Read in English →
Cuando la sincronización entre Lovable y GitHub "deja de funcionar", casi siempre es por una de cuatro razones: los commits fueron a una rama que Lovable no sincroniza, el aviso de GitHub nunca llegó a Lovable, los dos lados cambiaron la misma rama y se separaron, o Lovable perdió acceso al repositorio. Las cuatro se ven en la tarjeta de estado de Project settings → Git → GitHub, y cada una tiene su arreglo. Volver a empujar lo mismo casi nunca sirve.
A continuación: cómo funciona la sincronización en realidad, cómo leer esa tarjeta, una tabla de síntomas, cómo recuperar trabajo que un push reemplazó y una forma de organizar las ramas para que tú y un desarrollador no se pisen.
¿Cómo funciona la sincronización con GitHub?
Según la documentación de Lovable sobre GitHub, la sincronización va en los dos sentidos, pero con límites claros:
- Una sola rama a la vez. Lovable edita y sincroniza una rama, por defecto la rama principal del repositorio (casi siempre
main). Lo que subas a otra rama no aparece en Lovable hasta que se fusione con esa. - Solo exporta. Al conectar un proyecto, Lovable siempre crea un repositorio nuevo. No puedes conectarlo a un repositorio que ya tenías.
- Un repositorio por proyecto, en un solo proveedor (GitHub, GitLab o Bitbucket).
- Lovable guarda su propia copia de la rama. Por eso reescribir el historial en GitHub da problemas después.
En GitHub, cambiar el nombre del repositorio o de tu cuenta no corta la sincronización. Borrar el repositorio sí.
¿Cómo leo el estado de la sincronización?
Entra a Project settings → Git → GitHub. La tarjeta compara los últimos commits de cada lado y muestra algo como esto:
- Los dos lados en el mismo commit: no hay nada que hacer. Si tu cambio no aparece, probablemente está en otra rama.
- GitHub is N commits ahead of Lovable: Lovable todavía no trajo esos commits.
- Lovable and GitHub have diverged: cada lado tiene commits que el otro no tiene.
- Couldn't check GitHub right now: la comparación falló. Vuelve a intentarlo con Re-check.
El botón Re-check solo vuelve a comparar. No trae ni envía nada, y eso sorprende a mucha gente.
¿Qué está causando mi problema?
| Síntoma | Causa probable | Qué hacer |
|---|---|---|
| Mis commits nunca aparecen en Lovable | Están en otra rama | Fusiónalos en la rama sincronizada o cambia la rama en el selector |
| Dice que GitHub va adelante y no cambia | Lovable no recibió el aviso del push | Sube un commit nuevo a la rama sincronizada (puede ser vacío) |
Los cambios de Lovable quedaron en una rama lovable-sync | GitHub rechazó el push: rama protegida o commits en conflicto | Revisa lovable-sync y fusiónala con un pull request |
Apareció una rama lovable-fallback | Alguien borró la rama sincronizada en GitHub | Cambia a otra rama o vuelve a crear la original |
| Dejó de sincronizar tras subir videos o imágenes | Un archivo supera el límite de 100 MB de GitHub | Quita el archivo y deja que reintente |
| Aparece un aviso de Reconnect | La app de Lovable en GitHub se suspendió, se desinstaló o perdió acceso | Sigue los pasos de Reconnect y devuelve el acceso al repositorio |
¿Cómo resuelvo cada caso?
Commits en la rama equivocada
En los ajustes de GitHub del proyecto, abre el selector de ramas. Si dice main y tú subiste a feature/login, abre un pull request hacia main y fusiónalo, o cambia Lovable a feature/login. Ten en cuenta que una rama creada desde ese selector parte de la rama activa, no necesariamente de main.
GitHub va adelante y no pasa nada
Lovable trae los cambios cuando GitHub le avisa de un push. Si ese aviso se pierde, los commits no aparecen hasta el siguiente push. La solución que documenta Lovable es empujar de nuevo:
git commit --allow-empty -m "Forzar sincronización con Lovable"
git pushAntes de hacerlo, confirma que tus últimos cambios hechos en Lovable ya están en GitHub. Si la tarjeta dice que los lados se separaron, este push reemplaza la versión de Lovable por la de GitHub.
Los dos lados se separaron
Pasa cuando alguien edita en Lovable mientras otra persona empuja a la misma rama, o cuando se reescribe el historial. En vez de pisar tu trabajo, Lovable deja el suyo en lovable-sync. Abre esa rama en GitHub, compárala con main y fusiónala con un merge commit. Si los siguientes pushes también se rechazan, Lovable sigue sumando a lovable-sync, o crea lovable-sync-<fecha> si tú ya hiciste commits en ella.
Lovable perdió el acceso
Si un administrador cambió la app de GitHub de "All repositories" a "Only select repositories" y dejó fuera el tuyo, haz clic en Reconnect y vuelve a agregarlo en Repository access. Si la app se desinstaló, todos los proyectos vinculados se desconectaron: al reinstalarla se crea una conexión nueva, y al reconectar cada proyecto Lovable crea un repositorio nuevo. El viejo queda en GitHub, así que copia de ahí el historial que necesites.
¿Puedo recuperar trabajo que un push reemplazó?
Casi siempre. Cuando un push desde GitHub reemplaza commits de Lovable, Lovable guarda antes una copia y muestra A repository push replaced your Lovable work. Solo el dueño del proyecto puede entrar a Review restore y elegir Restore Lovable work. El aviso dura 24 horas; después, el dueño lo encuentra en Project settings → Git con Check for saved Lovable work.
Si no eres el dueño, avísale antes de que alguien vuelva a empujar.
¿Cómo comparten repositorio un desarrollador y Lovable?
La mayoría de los problemas vienen de dos personas editando la misma rama al mismo tiempo. Una organización sencilla lo evita:
- Lovable se queda en
main. - El desarrollador clona el repositorio y trabaja en una rama propia, nunca directo en
main. - Los cambios llegan a
mainpor pull request, con merge commit. - Nadie hace force-push, rebase ni squash de commits que ya están en
main. Para deshacer algo, se agrega un commit que lo revierte. - Mientras entra una fusión grande, no se escriben prompts en Lovable; después se revisa que la tarjeta muestre los dos lados en el mismo commit.
Si tu equipo exige pull request para todo cambio en main, pon a Lovable en su propia rama y fusiona su trabajo igual que el de cualquiera. La rama protegida va a rechazar sus pushes directos de todos modos.
Si el problema está en el código y no en la sincronización, la guía sobre cómo volver atrás cuando un agente de IA rompió tu código explica checkpoints y git revert. Y si vas a pasarle el repositorio a otra persona, lee qué preparar antes de entregar el proyecto a un desarrollador.
Respuestas rápidas
¿Por qué mis cambios de GitHub no aparecen en Lovable? Porque están en una rama que Lovable no sincroniza, o porque Lovable no recibió el aviso. Revisa primero el selector de ramas y luego sube un commit nuevo.
¿Re-check arregla la sincronización? No. Solo vuelve a comparar y muestra el resultado.
¿Puedo conectar Lovable a un repositorio que ya tengo? No con Git sync, que siempre crea uno nuevo. Lo que sí puedes es importar un ZIP con ese código como proyecto nuevo.
¿Es seguro renombrar el repositorio? En GitHub, sí: la sincronización sigue al nuevo nombre. Lo que la rompe es borrarlo.
¿Necesitas ayuda para desenredarlo?
Si las ramas se multiplicaron y nadie sabe cuál es la versión buena, vale la pena ordenarlo una vez con alguien que lo haga seguido. Empieza con el chequeo gratuito de tu app, mira cómo arreglamos apps de Lovable o escríbenos con los detalles.
