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, the connection lives 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.
  • 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 can be reused by any project in it. A workspace can hold 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. Linking a project creates a new repository and starts two-way sync automatically.
Once linked:
  • Edits made in Lovable are committed and pushed to your repository.
  • Commits pushed to the synced branch flow back into your Lovable project.
  • Synced commits go through the same checks as edits made in Lovable. If they change your dependencies, the dependency audit runs 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.

​
Who can do what

  • 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.

​
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, and on GitLab and Bitbucket they are pushed 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. It 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. Disabling it stops attribution on 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

Disconnecting a project stops the sync, nothing more:
  • Your repository stays on GitHub, GitLab, or Bitbucket, intact with all history and files.
  • Your project and its code stay in Lovable. Future changes are stored only in Lovable.
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.

​
Limitations

These apply to every provider:
  • Export only. You can’t import an existing repository into Lovable. Connecting a project always creates a new repository.
  • One repository per project. Each Lovable project links to exactly one repository.
  • One branch at a time. Only the synced branch flows back into Lovable.
  • Keep the repository where it is. Don’t move or delete a connected repository, or rename the account, organization, group, or workspace it lives in. Doing so breaks the sync. You can rename the repository itself on GitHub and Bitbucket, but on GitLab a rename 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 like 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 hold GitHub, GitLab, and Bitbucket connections side by side, and different projects can sync to different providers. A single project links to one repository on one provider.
No. Pushing commits syncs your code into Lovable 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. To export data, see Export Lovable Cloud data.
No. Git sync only exports from Lovable. Connecting a project creates a new repository.
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. Disabling Include member email addresses in commits stops Lovable from adding the address to new commits, but it cannot change commits that are already in your repository. Removing them means rewriting 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. Disconnecting never deletes code on either side.