Lovable GitHub Sync: Why It Breaks

Connecting Lovable to GitHub is the first thing we ask every client to do, before we touch a line of their code. It’s also where a surprising number of projects are quietly broken. The Lovable GitHub integration looks simple in the settings panel, and it mostly is, but it has a handful of rules that aren’t obvious until one of them bites you. Usually that happens the week a real developer joins the project.

Quick recap of how it works, because everything below follows from it. You connect a GitHub account or org to your Lovable workspace once (that installs the Lovable GitHub app), then link each project to a repository. Lovable creates that repository for you, private by default. From then on it’s two-way: every change you make in chat becomes a commit authored by lovable-dev[bot], and anything pushed to the synced branch flows back into the editor.

The word doing the heavy lifting there is “branch”. Singular.

Only one branch syncs

Lovable watches exactly one branch, normally main. Pushes to any other branch don’t exist as far as the editor is concerned.

We had a founder come to us after two weeks of paying a freelancer. The freelancer had done real work: fixed the auth redirect, split a 900-line Dashboard.tsx into components, added Zod validation to the forms. All of it lived on a branch called develop, merged in from three feature branches, with a PR to main that nobody had clicked. The founder kept prompting Lovable to “fix the dashboard” and burned credits rewriting code that was already fixed one branch over. Then someone finally merged the PR, and the conflict resolution took an afternoon, because Lovable had been editing the same files the whole time.

You can switch the synced branch now. Project settings, GitHub, branch picker, and you can even create a branch there, which Lovable cuts from whatever branch is currently active. That’s useful, but it doesn’t fix the underlying problem. Whichever branch Lovable is on, it commits straight to it. There’s no PR from Lovable to you. If a developer and the Lovable chat are both editing the same branch, you’re going to get collisions.

Our rule on client projects: once a developer is involved, Lovable stays on main and the developer works on branches and merges in. Small, frequent merges. Nobody prompts Lovable while a big merge is in flight.

”GitHub is ahead” and nothing happens

This one looks scary and isn’t. You push a commit, the sync status says GitHub is ahead, and the editor never picks it up. Lovable listens for GitHub’s push events, and occasionally one gets missed. The fix from Lovable’s own docs is to push something new so a fresh event fires. An empty commit is enough:

git commit --allow-empty -m "trigger lovable sync"
git push

If it still doesn’t move, check that you actually pushed to the synced branch. Nine times out of ten, that’s the real answer.

The mysterious lovable-fallback branch

If you delete the synced branch on GitHub (easy to do by accident, GitHub offers a “delete branch” button right after you merge a PR), Lovable has nowhere to write. It creates a branch called lovable-fallback and keeps going there. So now your app’s newest code is on a branch nobody’s deploy pipeline watches. Switch the synced branch back to something real in the picker, merge lovable-fallback into it, and delete the fallback once you’re sure it’s empty.

Disconnecting doesn’t reset anything

This is the one that costs people actual money. When sync misbehaves, the instinct is to disconnect and reconnect, like turning a router off and on. Don’t.

You can’t reconnect a Lovable project to the same repository after disconnecting it. Reconnecting creates a brand new repo. The old one stays on GitHub with all its history, untouched, just no longer linked. Anything that pointed at the old repo is now pointing at a dead end: your Vercel or Netlify project, your CI, the deploy key a developer set up, the GitHub Actions secrets. One client “fixed” a sync problem this way on a Friday and their Netlify site kept deploying the old repo for nine days. Nobody noticed, because the old repo still built fine. It just never got new code.

Moving a project to a different Lovable workspace does the same thing: the GitHub link breaks during the transfer. Renaming the repo or your GitHub org is fine, Lovable follows the rename.

And the other direction doesn’t work either. You can’t import an existing repository into Lovable. Lovable creates the repo, never the other way around.

Files Lovable won’t sync

GitHub rejects files over 100 MB, and Lovable can’t save any file over 10 MB. Someone drops a 140 MB product video into public/, pushes, and the sync stops dead. Delete the file from the repo, push again, and host big media somewhere meant for it (Supabase Storage, Cloudflare R2, Mux for video). A git repo is the wrong place for it anyway.

What’s in the repo, and what isn’t

People connect GitHub expecting a full backup. It’s a backup of the code. Your React app is there, your edge function code under supabase/functions/, your SQL migrations, and supabase/config.toml. Your database rows are not. Neither are files in storage buckets, and neither are secret values. If you’re on Lovable Cloud, the repo alone won’t let you rebuild your app somewhere else. We wrote up what each Lovable export actually includes if you want the full list.

That gap matters most when you move off Lovable Cloud. The repo has the code, but config.toml still carries the old project ref, and the data and files have to come across separately. That’s most of what our Lovable Cloud to Supabase migration handles.

Permissions, briefly

Two things trip up teams. Only workspace owners and admins can install the GitHub app or add a connection, so an editor clicking “Connect GitHub” just gets stuck. And if your GitHub org uses an IP allow list, the connection fails until Lovable’s IP ranges are on it. If “Add account” does nothing at all, it’s your popup blocker. Really.

The app asks for write access to contents, pull requests, workflows and repo administration. That’s broad, but it needs most of it to create repos and push. If that makes you uneasy, connect a separate GitHub org just for Lovable projects and transfer repos out when you’re done.

If your Lovable app has reached the point where a developer is touching the repo and things keep drifting, that’s usually the sign it needs a proper handover. Here’s how we run ours, or just tell us what’s going on.