You connected GitHub and now nothing makes sense

The pattern goes like this. You connect your project to GitHub because a tutorial said to, put it online through another service, and from then on the editor behaves strangely: changes you made yesterday are gone, a fix you already paid for needs paying for again, and the live site and the editor disagree about what the app looks like. Nobody broke anything. You now have two copies of your project and no way to tell which one is winning.

What the connection actually does

Before you connected it, there was one copy of your project, inside Lovable. After you connect there are two: the one in the editor, and the one sitting in GitHub. The sync runs both ways. An edit in the editor gets pushed up; a change made on the GitHub side gets pulled down. That is fine while only one of them ever changes.

It stops being fine the moment a second tool writes to the GitHub copy. Ask ChatGPT or Claude to fix a file, paste the result into GitHub, and the editor pulls that version down over its own. If the editor also had work in progress, one of the two versions loses. Adding Vercel or Netlify puts a third thing in the chain, which is harmless by itself but means the site your users see is built from the GitHub copy, not from what you are looking at in the editor. That gap is where "it works in the preview but not live" comes from.

Work out which copy is real

Do this before you change anything else, because the answer decides everything after it.

1. Open your project on GitHub and look at the list of changes on the front page. Each entry has a timestamp and whoever made it. If the newest ones say something like "lovable", the editor is the thing writing. If they are yours, or another tool's, something outside the editor wrote last.
2. Open your live site. Does it match what you see in the editor preview, or does it look like an older version?
3. Find one specific thing you know you changed recently. Search for that same text on the GitHub side. Present in both and they are in sync. Present in only one and you have found the copy that is ahead.

Whichever copy has the work you care about is the one to protect. Everything else can be rebuilt from it.

Why the credits drain after you connect

This is the complaint that fills the forums, and it is usually not a billing bug. When the editor pulls down a version of the code it did not write, it has lost the thread of what it did and why. A small request then turns into the model rereading your whole project, guessing at structure it no longer recognises, and changing three files to fix one. You pay for the guessing. Two or three rounds of that and a button alignment has cost real money.

There is no setting that fixes it. Pick one place where code gets changed, and treat the other as read-only. If the editor is where you work, stop editing files on GitHub and stop pasting code from other chats into it. If you have moved on to editing outside the editor, stop asking the editor for changes.

Before you touch it again, take a copy you can name

The reason this is frightening rather than annoying is that you cannot point at a version and say "that one worked". A list of changes written by a machine gives you timestamps, not the knowledge of which state of your app was actually fine.

Once you know which copy is real, make the losing one match it rather than trying to combine the two by hand. Stitching together two versions of a file you cannot read is how people lose the good one.

The setup that stops it happening again

• One tool writes, everything else reads. Decide which, and write it down somewhere you will see it.
• Save a named copy every time the app is in a state you would be upset to lose, not once a week.
• Before you put a new version online, check that the thing going out is the version you just tested. If those two come from different places, they will drift apart.
• Keep the path from "my project" to "my live site" short enough that you understand it. Three services chained together from a tutorial will eventually fail, and you will be debugging a system you never saw whole.

Plyo exists for the first two. Your AI saves a named copy of every working state and puts the one you choose online, so the version you tested is the version your users get, and going back is picking a name from a list. If you already have the GitHub tangle, sort out which copy is real first. Plyo will still be here afterwards.