Skip to content
OTFotf
All posts

Can you import a GitHub repository into Lovable? Here is the current answer

D
DaveAuthor
7 min read
Can you import a GitHub repository into Lovable? Here is the current answer

If your application already lives in GitHub, it is natural to look for an Import repository button in Lovable. The current answer is narrower: Lovable can export and sync a Lovable project to a GitHub repository, but its GitHub integration does not import an existing repository into Lovable. The direction matters before you move a production codebase or connect a team account.

This guide explains what the documented workflow does, what it does not do, and how to choose a safe next step when your source of truth is already in GitHub.

First, check which direction you need

Lovable’s GitHub integration begins with a project in Lovable. You authorize a GitHub account or organization, connect the Lovable project, and Lovable creates a new repository for that project. Afterward, Lovable and GitHub sync changes on the active branch in both directions.

That is useful when you start in Lovable and want to back up the code, collaborate through GitHub, work locally, or deploy elsewhere. It is not an inbound import flow for an arbitrary repository you already own. The official GitHub integration guide lists importing existing GitHub repositories as unsupported.

A Lovable-origin project moves toward a new GitHub repository while an existing repository is stopped at the inbound boundary

The distinction is easy to miss because both workflows mention GitHub, commits, and sync. Ask one question before clicking Connect: where does the project currently live? If the working code is in Lovable, connecting GitHub creates its repository copy. If the working code is already in a GitHub repository, the documented integration will not attach that repository to a new Lovable project.

What the supported Lovable-to-GitHub setup does

The integration has two parts: a workspace connection that authorizes Lovable to access a GitHub account or organization, and a project link that connects one Lovable project to one repository. An owner or admin establishes the account connection. A project owner or admin connects the project. Lovable creates a new GitHub repository and starts two-way sync automatically.

The created repository is private by default. Check the owner and organization before connecting, especially when you build for a client or work across personal and company accounts. The GitHub app installation determines which account or organization Lovable can use. Grant access only to the repositories the team intends Lovable to manage; broad access is convenient but expands the permission boundary.

After connection, open the project’s GitHub settings to check the repository, sync status, active branch, and clone URLs. Lovable supports HTTPS, SSH, and GitHub CLI clone URLs. You can use one of those URLs to continue in a local editor:

git clone https://github.com/your-account/your-lovable-project.git
cd your-lovable-project

Use the actual HTTPS URL displayed in the project settings. If you prefer SSH or GitHub CLI, copy that URL instead. Before editing, check the current branch and sync status in Lovable so your local work starts from the commit the editor is using.

Same component. Web and mobile. One codebase.

The free, open-source SDK gives you components that work the same on web and mobile — one codebase. github.com/otf-kit/sdk

Get the free SDK

Know the branch boundary before you collaborate

Lovable edits and syncs one branch at a time. The default is usually the repository’s default branch, but the active branch is shown in project GitHub settings. Changes pushed to that active branch sync back into Lovable. Work on a different branch does not appear in the project until it is merged into the branch Lovable is tracking or you switch Lovable to that branch.

Lovable also supports creating and switching branches from the branch picker. Create a feature branch from the branch you intend to use as its base; the picker uses the currently active branch as the source. Avoid switching while Lovable is editing the project. For a team workflow, write down which branch is the handoff branch and merge reviewed work into it deliberately.

If Lovable and GitHub have diverged, the documented sync behavior changes: Lovable may push its edits to a lovable-sync branch rather than overwrite the branch with the other side’s commits. Stop and inspect the sync status before making more edits. Don’t assume a green-looking editor means both sides contain the same commit.

If your repository already exists

There is no supported “select an existing repo and import it” step in the current integration. Do not click Connect expecting Lovable to adopt the selected repository: the documented flow creates a new repository for the Lovable project instead. Also avoid disconnecting an existing GitLab or Bitbucket project as an experiment. Disconnecting ends that sync link, and reconnecting creates a new repository rather than restoring the old one.

If your goal is to keep shipping the existing codebase, keep GitHub as the source of truth and work in a local editor or your existing development workflow. You can clone the repository, install its dependencies, run its checks, and deploy through the process already attached to that repository. This does not put the project into Lovable’s editor, but it avoids creating a second competing repository and a manual merge problem.

If the team specifically needs a Lovable project, treat that as a separate migration decision rather than a normal import. Back up the source repository, inventory its build and environment requirements, and confirm the target project can run the same app before moving files. The supported GitHub integration still creates a new repository from a Lovable project; the docs do not promise that replacing its contents with an existing codebase will convert the project into a supported import. Do not put production secrets in the repository while testing a transfer.

For projects that began in Lovable and need a local codebase, the opposite direction is documented: connect the project to GitHub, then clone the repository. Our guide to turning a Lovable or Bolt export into an AI-friendly codebase covers the work after code has left the builder, including structure, conventions, and a clean handoff to a coding agent. That is a separate workflow from importing an existing GitHub project into Lovable.

Run a small, reversible check

A builder checks account ownership, the active branch, and two-way sync in a disposable test project

Before changing an established workflow, test the direction with a disposable project and a repository you can afford to replace. Verify each checkpoint:

  1. The GitHub account or organization shown in Lovable is the intended owner.
  2. Connecting creates a new, private repository for the Lovable project.
  3. The active branch shown in Lovable matches the branch you plan to use.
  4. A small, non-sensitive change made in Lovable appears on that branch in GitHub.
  5. A separate commit pushed to the active branch appears in Lovable.
  6. The project still builds from a clean local clone using the repository’s documented setup.

This checks the documented two-way sync without risking the existing source repository. If one direction fails, inspect the connection and sync status before continuing. Keep a backup and avoid doing parallel edits in Lovable and another editor until you know which branch is authoritative.

Choose the right path

Use Lovable’s GitHub integration when the project starts in Lovable and you want a repository for version control, local work, review, or deployment. If the code already lives in GitHub, the current integration does not import it into Lovable; keep developing from that repository unless you have a separately verified migration plan. For a Lovable-origin project moving outward, use the supported export and clone path, then test the build and deployment from the repository you control.

The safest decision is to name the source of truth before connecting anything. “GitHub sync” describes a supported two-way workflow after Lovable creates or connects its project repository. It does not mean every existing GitHub repository can be pulled into the Lovable editor. If you decide to begin from an owned repository, OTF Kit is at https://otf-kit.dev; choose a codebase your team can clone and maintain, rather than expecting an inbound import the current docs do not support.

Sources

ai-toolsagentslovable
OTF SDK + Kits

Buy once, own the code. Ship with the agent you already use.

  • Free, open-source SDK — same component, web and mobile
  • Paid kits include AI configs + 40+ tested prompts — your agent reads the whole project
  • $99/kit or $149 for everything. No subscription, no sandbox limit.
Need more than components?

Full-stack kits.
Pay once, own the code.

Auth, database, and payments already connected — so you ship product, not setup. Or take the delivered kits in the Bundle.

Everything Bundle — $149See full pricing

Get the free AI configs pack

Pre-tuned AI configs for Cursor, Claude, and Lovable — drop them in and your AI tool instantly understands your project.

No spam. Unsubscribe any time.

Prefer the free SDK? Star it on GitHub →