Skip to main content
When you build with Lovable, your project code is stored and managed inside the Lovable platform. Git sync connects a Lovable project to a repository you own on GitHub, GitLab, or Bitbucket, and keeps the two in sync automatically: changes you make in Lovable are committed to your repository, and commits pushed to the synced branch appear back in your Lovable project.
You don’t need Git to use Lovable. Many users build and launch entirely within Lovable. If you only need a copy of your code, use the Download codebase section in Project settings → Git, or open the Code editor and click Download codebase at the bottom of the file tree sidebar (paid plans).
This page explains how Git sync works across providers. In a project, you manage the connection in Project settings → Git. For setup steps, see the provider pages:
  • GitHub (github.com, GitHub Enterprise Cloud with data residency, or GitHub Enterprise Server)
  • GitLab (GitLab.com or a self-managed GitLab instance)
  • Bitbucket (Bitbucket Cloud)
Want your app to call the GitHub REST API to read repositories, issues, and pull requests instead? Use the GitHub API connector.

​
Why sync your project to a Git repository

  • Back up your code. Store your project safely outside Lovable, in an account you control.
  • Collaborate with developers. Use branches, pull or merge requests, and code reviews alongside building in Lovable.
  • Work locally in your IDE. Clone the repository, edit and commit locally, and push. Your changes sync back into Lovable. See Work locally in your IDE.
  • Deploy outside Lovable. Self-host or deploy to other platforms. See Deployment, hosting, and ownership options.
  • Keep a copy of your code within your own infrastructure. Sync to GitHub Enterprise Cloud with data residency, GitHub Enterprise Server (both Enterprise plan), or a self-managed GitLab instance.

​
How Git sync works

Git sync has two layers, on every provider:
  1. A workspace connection authorizes Lovable to access a Git account, organization, group, workspace, or instance. Connections belong to the workspace, and any project in the workspace can use them. A workspace can have multiple connections, including connections to GitHub, GitLab, and Bitbucket at the same time.
  2. A project repository link connects one Lovable project to one repository under one of those connections. When you link a project, Lovable creates a new repository and starts two-way sync automatically.
After you link a project:
  • Lovable commits the edits you make in Lovable and pushes them to your repository.
  • Commits you push to the synced branch appear in your Lovable project.
  • Synced commits go through the same checks as edits made in Lovable. If they change your dependencies, Lovable runs the dependency audit and updates the project’s Security view.
  • Lovable edits and syncs one branch at a time. Commits on other branches don’t appear in Lovable until you merge them into the synced branch or switch the synced branch. You can switch branches and create new branches from Lovable on every provider.

​
Sync status

The sync status card in Project settings → Git compares the synced branch in Lovable with the same branch on your provider. Each label names your provider. On a GitHub project, the card shows one of the following states:
  • In sync with GitHub: Lovable and GitHub are on the same commit.
  • Lovable is N commits ahead of GitHub: Lovable pushes these changes to GitHub on the next sync.
  • GitHub is N commits ahead of Lovable: Lovable hasn’t pulled these commits yet. If this state persists after you push, follow the troubleshooting entry for GitHub, GitLab, or Bitbucket.
  • Lovable and GitHub have diverged: Lovable and GitHub each have commits that the other does not. Lovable pushes its changes to a separate lovable-sync branch instead of the synced branch, and the next sync from GitHub replaces Lovable’s version of the branch with the GitHub version.
  • Couldn’t check GitHub right now or Sync state couldn’t be determined: the comparison failed, or the two histories don’t meet within the commits Lovable compares. Click Re-check to compare again.
Lovable compares the 50 most recent commits on each side, so a count can read 50+. The card also shows when Lovable last synced the branch and when it last checked the status. Click Re-check to compare the branches again. Re-check doesn’t sync anything.

​
Roles and permissions

  • Workspace owners and admins add, update, and delete workspace connections, and enable or disable commit attribution.
  • Workspace or project owners and admins connect and disconnect projects.
  • Editors and above view sync status and work with the synced repository.
The provider pages list the exact role requirements for each action.

​
Choose a provider

Each project links to one repository on one provider. All providers support the same core two-way sync. If your team already uses one of these platforms, use that one.

​
Work locally in your IDE

When a project syncs with a repository, you can clone that repository, edit the code with your own IDE or coding assistant, and push the result back. Commits on the synced branch appear in your Lovable project, and you continue building on them in Lovable. Repository access and project access are separate. To push, you need write access to the repository on your Git provider. To keep building in Lovable, you need an editor role on the project. Check the README and package.json in the repository for what you need installed and for the commands that install dependencies and start the app.

​
Keep Lovable and your work on separate branches

Lovable edits and syncs one branch at a time. The branch picker in Project settings → Git shows which one. Keep Lovable on that branch, usually main, and make your local changes on a feature branch. The feature branch stays out of your Lovable project until you merge it into the synced branch, so unreviewed work does not reach the project. When you merge, Lovable pulls the result. Do not force-push, rebase, or squash commits that are already on the synced branch. Lovable keeps its own copy of that branch. When you rewrite its history, the next sync replaces Lovable’s copy with yours, and edits made only in Lovable can be lost. To undo a change, add a commit that reverts it. If your team requires a pull or merge request for every change to main, switch Lovable to a feature branch of its own and merge its work through the same review process. Your Git provider rejects Lovable’s pushes to a protected branch, and Lovable then pushes to the lovable-sync branch instead. See the troubleshooting entry for GitHub, GitLab, or Bitbucket.

​
Hand over work between Lovable and your IDE

Before you clone or merge, let any Lovable edit in progress finish and check the sync status card. When the card reports that Lovable and your provider are in sync, your local copy starts from the latest Lovable changes. After you merge, the card shows the in-sync state again when Lovable has pulled your commits.

​
Check the environment before you run the app

A clone gives you the code, not the services the app calls. In a project that uses Lovable Cloud, the repository’s .env file carries the URL and publishable key of your Cloud backend, for example as VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY. A local app that keeps that configuration reads and writes the same backend as your published app, so records you create or delete locally change real data. Use test accounts and records while you test writes. A Git branch does not give you a separate database.
Variables prefixed with VITE_ are included in the code your app sends to the browser. Do not add a service role key or any other secret to them.
The repository does not carry everything sign-in and server-side calls need. An authentication provider redirects only to URLs it knows, so add your local URL where your provider configures redirect URLs. Secrets you store in Lovable stay out of the repository, so server-side code that reads them needs those values wherever it runs. The credentials behind app + chat connectors and Lovable AI are managed by Lovable and cannot be copied out. In an older React + Vite app, those calls run in Edge Functions on your Cloud backend, so a local app that uses that backend can still make them. In a newer app (created from May 13, 2026, which uses TanStack Start), the server code runs on your machine, so connector and AI calls fail locally. Test them in the Lovable preview or in your published app. When the app works in Lovable but a request fails locally, check the service that request reaches.

​
Backend files in your commits

In a project that uses Lovable Cloud, the repository also contains your backend code: Edge Functions under supabase/functions/ and the migration files under supabase/migrations/ that record your database structure. Lovable does not deploy a changed Edge Function or run a new migration file when your commits sync.
  • Edge Functions: after the commit syncs, ask Lovable in the project chat to deploy the function, then check it under More → Cloud → Edge functions.
  • Migrations: to change the database structure, ask Lovable in the project chat, or run the SQL yourself in the SQL editor.

​
Continue building in Lovable

After your merge reaches the synced branch and the sync status card shows both sides in sync, open the changed files in the code editor and test the behavior in the preview. Then tell Lovable what changed, so its next edit builds on your work:
A merge does not change your published app. When the change is ready for your users, publish again. Lovable treats code you wrote the same as code it generated, and it can change either in a later request. Put constraints that should hold across requests in project knowledge, and keep tests for behavior you depend on. See Test and verify your app for the testing tools in Lovable.

​
Commit attribution

Commits that Lovable pushes are not authored by the workspace member who triggered them. On GitHub they come from the Lovable GitHub app. On GitLab and Bitbucket, Lovable pushes them through the account that authorized the workspace connection. For how each platform still credits the member behind a change, see commit attribution for GitHub, GitLab, and Bitbucket. To record who triggered each change, a workspace owner or admin can enable Include member email addresses in commits in Workspace settings → Git → Commit attribution. The setting is available on the Business and Enterprise plans and is disabled by default. On other plans the section does not appear. While it is enabled, commits Lovable makes on a member’s behalf carry that member’s email address on its own line in the commit message body:
Not every commit carries an address. Commits Lovable makes on its own, such as when you publish a project, carry none, and neither do commits from someone who was invited to a single project rather than to the workspace. The setting matters most for members whose changes are not already attributed. On a GitHub repository, Lovable co-attributes each commit to the GitHub account of the member who triggered it. If that member has connected a GitHub account, GitHub already links most of their commits to their profile. The setting adds a record in two cases:
  • Members with no connected GitHub account. Lovable cannot co-attribute their commits at all, so without this setting nothing in the repository records who triggered the change.
  • GitLab and Bitbucket repositories. Lovable does not add the co-author line on these providers, so without this setting nothing in the repository records who triggered the change.
Enable it when you need to trace a change back to a person, for example for code review, audits, or internal reporting. Leave it disabled for public repositories. When you disable it, Lovable stops adding addresses to new commits. A change already in progress finishes with the setting it started with.
Not recommended for public repositories. Email addresses in commit messages are visible to everyone who can read the repository’s history, including people outside your workspace, and a public repository makes them readable by anyone on the internet. Lovable cannot rewrite Git history, so addresses in commits you already pushed stay in your repository after you disable the setting.

​
Disconnecting and reconnecting

When you disconnect a project, Lovable stops the sync and changes nothing else:
  • Your repository stays on GitHub, GitLab, or Bitbucket, intact with all history and files.
  • Your project and its code stay in Lovable. Changes you make afterwards stay in Lovable only.
If you reconnect a project later, Lovable creates a new repository with the current version of your project. The original repository stays in your account but is no longer linked. To move a project to a different provider, disconnect it first. While a project is linked, Project settings → Git shows only the connected provider’s card, with a notice under it, for example “This project syncs with GitHub. A project can use one Git provider at a time — disconnect it to switch.” After you disconnect the project, the GitHub, GitLab, and Bitbucket cards all appear again, and you can connect the project to any of them.

​
Limitations

These apply to every provider:
  • Export only. You can’t import an existing repository into Lovable. When you connect a project, Lovable always creates a new repository.
  • One repository per project. Each Lovable project links to exactly one repository on one provider. To switch providers, disconnect the project first.
  • One branch at a time. Only commits on the synced branch appear in Lovable.
  • Keep the repository where it is. Deleting a connected repository stops the sync. On GitHub and Bitbucket, the sync follows a renamed repository, a renamed account, organization, or workspace, and a repository moved to another account, organization, or workspace that your Lovable workspace also has a connection to. A move to a destination without a connection disconnects the project. On GitLab, a rename or move of the project or its group breaks the sync.
  • Reconnecting creates a new repository. You can’t re-link a previously disconnected repository.
  • No sync for drafts. A draft doesn’t appear as a branch in your repository. Its code reaches the repository after you accept the draft, like any other project change.

​
FAQ

No. Set up the connection once and your code is safely stored in your repository. You only need Git knowledge for advanced workflows such as branching, pull or merge requests, or CI/CD.
No. On paid plans you can download your code directly: use the Download codebase section in Project settings → Git, or click Download codebase in the Code editor. Git sync is for ongoing two-way sync and collaboration.
A workspace can have connections to GitHub, GitLab, and Bitbucket at the same time, and different projects can sync to different providers. A single project links to one repository on one provider. To switch a project to a different provider, disconnect it first.
No. When you push commits, Lovable syncs your code and updates the preview in the editor, but it never publishes. Your live site only changes when you publish from Lovable. See Publish your project.
No. The repository contains your project’s code, including the database migration files that define its structure, but never the data inside your database. Lovable does not run migration files that you add through Git. See Backend files in your commits. To export data, see Export Lovable Cloud data.
No. Git sync only exports from Lovable. When you connect a project, Lovable creates a new repository.
Yes. Lovable receives the commits you push to the synced branch regardless of which tool made them, so any IDE or coding assistant that works with Git is supported. See Work locally in your IDE.
You use no Lovable credits when you edit and commit code on your computer. A change you ask Lovable to make in the project chat consumes credits as usual. Calls your local app makes to your Cloud backend or through the AI Gateway count as Cloud and AI usage, the same as calls from your published app. External services bill you directly for the calls your app makes to them. See Credits and usage.
Your changes become part of the project’s code when they sync, and Lovable builds on them. Lovable can also edit that code in a later request, the same as code it generated. To protect behavior you depend on, describe the constraint in project knowledge and cover it with tests.
Usually not. On a GitHub repository, Lovable already co-attributes each commit to the GitHub account of the member who triggered it, so their changes are linked to their GitHub profile. On a Business or Enterprise plan, enable Include member email addresses in commits when some members have no connected GitHub account, or when you sync to GitLab or Bitbucket, where Lovable does not add the co-author line.
Not from Lovable. When you disable Include member email addresses in commits, Lovable stops adding the address to new commits, but it cannot change commits that are already in your repository. To remove them, you must rewrite the repository’s Git history yourself, which changes every affected commit.
Yes. Your project remains fully editable in Lovable. The repository is a synced copy that you own. When you disconnect, Lovable deletes no code on either side.