Lovable GitHub sync: how it really works

Lovable’s Git sync is a genuine two-way mirror that keeps running after the first export. (If you only want the initial export, here’s a step-by-step walkthrough with screenshots.) Changes you make in the editor land as commits in your repository, and commits you push to the active branch flow back into Lovable. It syncs exactly one branch, it can never import a repository you already have, and pushing code does not deploy anything. Those three facts explain most of the confusion around it.

This is the reference version: every documented rule, every limit, what breaks the connection, and what to do when a push claims success and nothing moves. If you are working through a wider exit, start with the full Lovable migration guide and come back here for the git layer.

The short version#

• Git sync supports GitHub, GitLab and Bitbucket Cloud.
• Sync is two-way, but Lovable edits and syncs one branch at a time, defaulting to the repository’s default branch. Only that branch flows back in.
• You cannot import an existing repository. Connecting always creates a new one.
• Each Lovable project maps to exactly one repository on exactly one provider, private by default.
• Pushing commits does not update your published site. Publishing is a separate snapshot action.
• Renaming the repository is safe. Transferring it, deleting it, or renaming your GitHub account or organization breaks the connection.
• Disconnect is effectively one-way: reconnecting creates a second, new repository rather than re-attaching the original.

Which providers does it actually support?#

Most writing about Lovable assumes GitHub is the only option. Per the Git sync overview docs, three providers are supported:

On the two Enterprise GitHub variants you create your own copy of the Lovable GitHub app rather than installing Lovable’s public one. Both are Enterprise-plan only.

One caveat worth checking against your own account before you plan around it: the docs list github.com sync as available on all plans, while the subscription-plans page says the Free tier has no code editing and no code downloads. Those statements are about different things, but the boundary is fuzzy enough that you should confirm on the plan you are actually on.

The failure modes documented below are the ones Lovable publishes on its GitHub integration page. Do not assume GitLab and Bitbucket behave identically on repository renames or transfers: that has not been documented the same way.

How do you connect a project, and what is the button called?#

There is no “Export to GitHub” button. The action is Connect, and Lovable’s docs describe the feature as “export and two-way sync.”

First-time setup for github.com runs like this:

1. Add the account. Lovable opens a GitHub popup.
2. Choose the account or organization the repository should live in.
3. Choose All repositories or Only select repositories.
4. Install & Authorize.
5. Lovable detects the installation and registers it as a reusable workspace connection.

After that, you click Connect next to the workspace connection where the new repository should be created. The repository is created for you, private by default.

Getting the destination right on this first connect matters more than anything else in this post. Because you cannot import a repository and cannot re-attach one after disconnecting, the org you pick here is effectively permanent unless you are willing to start a new repository and lose the commit history.

What permissions does the GitHub app request?#

The Lovable GitHub app asks for Contents (write), Metadata (read), Pull requests (write), Workflows (write) and Administration (write).

Administration:write is the one that raises eyebrows in a security review. It is what allows Lovable to create the repository for you, which is the whole basis of the export-only model. If your org requires justification for app permissions, that is the justification, and it is also a reason to scope the installation to selected repositories rather than all of them.

Commits are authored by lovable-dev[bot] on github.com and GitHub Enterprise Cloud, or <your-app-name>[bot] on Enterprise Server, and co-attributed to the workspace member who triggered the sync. So git log shows a bot as the author, with the workspace member who triggered the sync co-attributed on the commit. If you have CI rules, required signed commits, or CODEOWNERS logic keyed to human authorship, test them before you rely on them.

Why “two-way” only means one branch#

Both directions genuinely work. Lovable’s docs state that changes made in Lovable sync to GitHub, and that changes pushed to the active GitHub branch sync back into Lovable.

The constraint sits underneath that: Lovable only edits and syncs one branch at a time, which defaults to the repository’s default branch, and only the synced branch flows back into Lovable. Work you push to any other branch is invisible inside the editor until it reaches the synced branch.

You can switch the active branch or create a new one from Lovable’s branch picker, with two rules attached:

• A new branch is cut from the currently active branch, which may not be the repository’s default. If you switched to staging earlier and forgot, your new branch starts from staging.
• You cannot switch branches or create branches while Lovable is actively editing the project. Let the current message finish first.

This single-branch model is the root cause of the merge pain people hit when they run Lovable and an IDE side by side. More on that below.

What lands in the repository, and what never does#

The repository contains your application source. It does not contain your application.

Database data is never in the repo. What you get are the migration files that define the schema. Secrets are not there either, by design. Storage objects, deployed backend state and the running configuration of your app all live on the platform side. Cloning the repo gets you the codebase, and you still have to rebuild the backend around it. Most people discover that a week into a migration.

Two practical consequences:

# 1. Work out which stack you are on before doing anything else.
#    Old projects: React + Vite. New projects (13 May 2026+): TanStack Start with SSR.
grep -E '"(@tanstack/react-start|@tanstack/react-router|react-router-dom)"' package.json

# 2. Find the secrets your backend code expects, so you know what you must
#    re-create rather than copy (Lovable's secret values are not exported).
grep -rEo "(Deno\.env\.get\(['\"]|process\.env(\.|\[['\"])|import\.meta\.env\.)[A-Z0-9_]+" src supabase 2>/dev/null | sort -u

Frontend variables show up as import.meta.env.VITE_* and are baked into the client bundle at build time. Edge-function secrets show up as Deno.env.get(...) and only ever exist on the server. Both lists matter, for different reasons: the first tells you what to put in a local .env, the second tells you what to re-create in whatever backend you land on.

If you only wanted the files and not an ongoing mirror, a point-in-time ZIP download of your Lovable code is the simpler route and does not create a repository you then have to look after.

File size limits#

Two separate ceilings, often confused:

• 100 MB is GitHub’s own per-file limit. Files above it fail to sync.
• 10 MB is Lovable’s in-editor limit. Files above that size cannot be edited inside Lovable; the 100 MB GitHub limit is the one that actually blocks a file from syncing.

Design assets, seed data dumps and vendored binaries are where this bites. Lovable’s docs don’t say what error, if any, you see when a file crosses either limit, so if a large asset seems to have vanished from one side, check its size first.

Pushing commits does not deploy your site#

This is the most expensive misunderstanding in the whole feature, because it fails quietly and looks like a caching problem.

Git sync and publishing are separate systems. Lovable’s Git sync overview says publishing your site happens separately and that pushing commits does not automatically update the live site. The hosting docs describe publishing as a snapshot: changes made after you publish do not affect the live site until you publish again, and the editor preview is not the published site. There is no separate staging environment: the flow is build, preview in the editor, publish.

So a commit pushed from your IDE travels: GitHub → Lovable’s synced branch → the editor. It stops there. The live URL keeps serving the last snapshot you published until you publish a new one.

What breaks sync, and what is safe#

Lovable documents four distinct outcomes. Only one of them is harmless.

Lovable’s own warning is blunt: don’t delete the repository, rename your GitHub account or organization, or transfer the repository to another account or organization, because doing so breaks the sync and Lovable will not be able to update your project.

The transfer case causes the most damage because moving a personal repo into a company org is an ordinary, responsible thing to do, and GitHub’s Transfer button gives you no hint that anything downstream depends on the owner. A third-party migration write-up on DEV.to reports that after a transfer, reconnecting does not accept the moved repository and Lovable generates a suffixed name such as my-org/my-app-1 instead. Treat that as a plausible report rather than documented behavior, but it matches the documented rule that reconnect always creates a new repository.

Disconnect is a destructive button#

When you disconnect, sync stops, the repository stays on GitHub with its full history, and your project and code stay in Lovable. Nothing is deleted. But reconnecting to the same repository after disconnecting is on the unsupported list: Lovable creates a new repository on reconnect, seeded with the current state of the project.

A disconnect/reconnect cycle therefore orphans the original repository and its commit history. There is no undo, and “just reconnect it” is not a recovery plan.

Moving a project into a company org without wrecking it#

The order matters. If the project is not connected yet, do this:

1. Install the Lovable GitHub app on the organization first, scoped to selected repositories if your security team prefers.
2. Connect the Lovable project and choose the organization as the destination so Lovable creates the repository there from the start.

If it is already connected to a personal repo, you are choosing between two imperfect paths:

1. Transfer and escalate. Move it with GitHub’s Transfer button, accept that sync is broken, and contact Lovable support to re-attach the connection. This is the only documented route that preserves the repository.
2. Rebuild the connection. Disconnect in Lovable, rename the old repository to something like my-app-legacy and archive it, then reconnect targeting the org so Lovable creates a fresh repository there. You keep the old history as an archive, but the new repository starts clean, and any GitHub-side configuration (branch protection, Actions secrets, environments, webhooks) has to be rebuilt.

Either way, the history question is worth settling before you start. If you need the old commits in the new repository, push the archived repo as an additional remote or merge it in with --allow-unrelated-histories after the new one exists. The wider handover checklist (workspace ownership, domain, database, analytics, payment accounts) is covered in moving a Lovable project to another repo.

Troubleshooting: “push succeeded but the repo never changed”#

Work through this in order. The failure modes have different causes and the cheap checks come first.

1. Look for a lovable-sync branch. When a push fails because of branch protection or a conflict, Lovable’s docs say it pushes the work to a branch named lovable-sync instead. Your code is not lost, it is on a branch you were not watching.

git fetch --all --prune
git branch -r | grep -i lovable
git log --oneline origin/lovable-sync -10

2. Confirm which branch is actually synced. Lovable syncs one branch, defaulting to the repository default. If someone changed the active branch in Lovable, or changed the default branch on GitHub, you can be watching main while Lovable writes elsewhere.

3. Check status.lovable.dev before you debug your own setup. Two-way sync has had at least one multi-day incident (20 to 23 March 2026, roughly three days and eight hours) with GitHub commit cards not rendering in the Lovable UI and commit changes not reflected in live or static preview. The published resolution was to push a fresh commit to retrigger sync.

4. Push a fresh commit to retrigger. Pushing a new commit to the synced branch is the documented recovery for at least one past incident. Push it to the branch Lovable reports as active in the branch picker: the one you confirmed in step 2. Pushing to main when it isn’t the active branch reproduces the same silent no-op you are trying to diagnose. An empty commit may be enough; a one-character whitespace change definitely alters the tree, so reach for that if the empty one does nothing.

git commit --allow-empty -m "chore: retrigger Lovable sync"
git push origin <your-synced-branch>   # the branch Lovable has active, from step 2

5. Check the GitHub app installation. Confirm the Lovable app is still installed on the owning account or org, that the repository is still inside its selected-repositories scope, and that no one revoked or reduced its permissions. Adding a repository to an org after the fact does not grant access if the installation is scoped to a list.

6. Ask whether the connection itself is gone. If the Lovable UI has collapsed to a first-time-connect screen, or it repeatedly asks you to reconnect, the problem is the repository binding itself. Do not click Connect: that creates a second repository. Check first whether the repo was transferred, deleted, or whether the account or org was renamed, and reverse that if you can. If it was a transfer, contact support.

7. Then check the boring one. If GitHub has the commit and the editor has the change but your domain does not, you have not published. See the section above.

Running Lovable and an IDE against the same project#

Because there is one synced branch, two writers on that branch means manual conflict resolution. The overlaps cluster in predictable places: package.json, route files, generated components and configuration files: exactly the files both an AI editor and a human touch most often.

A discipline that holds up:

• Treat the synced branch as Lovable’s branch. Nothing else writes to it directly.
• Do IDE work on feature branches and merge into the synced branch deliberately, in one direction, when Lovable is idle.
• Never start a Lovable message while you have unpushed local work on the synced branch.
• Remember that branch creation in Lovable forks from the active branch, so check which branch is active before you cut a new one.
• As of 9 September 2026 Lovable also has Drafts: separate copies of a project for testing changes before merging into the main version. Lovable’s docs don’t say how Drafts interact with Git sync, so check what lands in your repository before you rely on a draft to keep work off the synced branch.

At some point the honest answer is to stop editing in Lovable altogether and treat the repository as the source of truth. That handoff decision, and what you give up, is the subject of Lovable vs Cursor.

What to do next#

1. Open your repository and check who owns it. If it is a personal account and the project is going to outlive the prototype, fix that now, before there is history worth keeping.
2. Run git branch -r | grep -i lovable once, today, to find out whether a lovable-sync branch has been quietly collecting your pushes.
3. Confirm which branch Lovable has active and make sure it is the branch your CI runs on.
4. Publish, then diff your live site against the editor preview, so you know for certain whether your last few commits ever reached production.
5. Write down the repository owner, the synced branch and the publish step somewhere your team can read. Every failure mode in this post starts with somebody not knowing one of those three.