---
title: "Sync your RShift Sites project code with GitHub, GitLab, or Bitbucket"
description: "Git sync keeps your RShift Sites project code in your own GitHub, GitLab, or Bitbucket repository with automatic two-way sync, so you can back up code, collaborate with developers, work in your IDE, and deploy anywhere."
image: "https://help.rshift.com/og.svg"
---

> Documentation Index
> Fetch the complete documentation index at: https://help.rshift.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Sync your RShift Sites project code with GitHub, GitLab, or Bitbucket

When you build with RShift Sites, your project code is stored and managed inside the RShift Sites platform. Git sync connects a RShift Sites project to a repository you own on GitHub, GitLab, or Bitbucket, and keeps the two in sync automatically: changes you make in RShift Sites are committed to your repository, and commits pushed to the synced branch appear back in your RShift Sites project.

> **Note**
>
> You don't need Git to use RShift Sites. Many users build and launch entirely within RShift Sites. If you only need a copy of your code, use the **Download codebase** section in [**Project settings → Git**](/sites/features/projects/settings/#git-tab), or open the [Code editor](/sites/features/code-mode/) 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**](/sites/features/projects/settings/#git-tab). For setup steps, see the provider pages:

* [GitHub](/sites/integrations/github/) (github.com, GitHub Enterprise Cloud with data residency, or GitHub Enterprise Server)
* [GitLab](/sites/integrations/gitlab/) (GitLab.com or a self-managed GitLab instance)
* [Bitbucket](/sites/integrations/bitbucket/) (Bitbucket Cloud)

> **Note**
>
> Want your app to call the GitHub REST API to read repositories, issues, and pull requests instead? Use the [GitHub API connector](/sites/integrations/github-api/).

## Why sync your project to a Git repository

* **Back up your code.** Store your project safely outside RShift Sites, in an account you control.
* **Collaborate with developers.** Use branches, pull or merge requests, and code reviews alongside building in RShift Sites.
* **Work locally in your IDE.** Clone the repository, edit and commit locally, and push. Your changes sync back into RShift Sites.
* **Deploy outside RShift Sites.** Self-host or deploy to other platforms. See [Deployment, hosting, and ownership options](/sites/tips-tricks/deployment-hosting-ownership/).
* **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 RShift Sites 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 RShift Sites project to one repository under one of those connections. When you link a project, RShift Sites creates a new repository and starts two-way sync automatically.

After you link a project:

* RShift Sites commits the edits you make in RShift Sites and pushes them to your repository.
* Commits you push to the synced branch appear in your RShift Sites project.
* Synced commits go through the same checks as edits made in RShift Sites. If they change your dependencies, RShift Sites runs the [dependency audit](/sites/features/security/#identifying-vulnerabilities-in-dependencies) and updates the project's [Security view](/sites/features/security-view/).
* RShift Sites edits and syncs **one branch at a time**. Commits on other branches don't appear in RShift Sites until you merge them into the synced branch or switch the synced branch. You can switch branches and create new branches from RShift Sites on every provider.

### Sync status

The sync status card in [**Project settings → Git**](/sites/features/projects/settings/#git-tab) compares the synced branch in RShift Sites 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**: RShift Sites and GitHub are on the same commit.
* **RShift Sites is N commits ahead of GitHub**: RShift Sites pushes these changes to GitHub on the next sync.
* **GitHub is N commits ahead of RShift Sites**: RShift Sites hasn't pulled these commits yet. If this state persists after you push, follow the troubleshooting entry for [GitHub](/sites/integrations/github/#project-repository-issues), [GitLab](/sites/integrations/gitlab/#troubleshooting), or [Bitbucket](/sites/integrations/bitbucket/#troubleshooting).
* **RShift Sites and GitHub have diverged**: RShift Sites and GitHub each have commits that the other does not. RShift Sites pushes its changes to a separate `lovable-sync` branch instead of the synced branch, and the next sync from GitHub replaces RShift Sites' 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 RShift Sites compares. Click **Re-check** to compare again.

RShift Sites compares the 50 most recent commits on each side, so a count can read **50+**. The card also shows when RShift Sites 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](#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.

|                         | GitHub                                                                                          | GitLab                                                 | Bitbucket                                              |
| ----------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------------------------ |
| Hosted service          | github.com (all plans)                                                                          | GitLab.com (all plans)                                 | Bitbucket Cloud (all plans)                            |
| Your own infrastructure | GitHub Enterprise Cloud with data residency, or GitHub Enterprise Server (both Enterprise plan) | Self-managed GitLab instance (all plans)               | Not available (Bitbucket Data Center is not supported) |
| Connection method       | RShift Sites GitHub App (or your own copy of it on Enterprise Server)                                | OAuth with your GitLab account                         | OAuth with your Atlassian account                      |
| Synced branch           | Active branch: switch and create branches from RShift Sites                                          | Active branch: switch and create branches from RShift Sites | Active branch: switch and create branches from RShift Sites |
| Repository renames      | Followed automatically                                                                          | Break the sync                                         | Followed automatically                                 |

If your team already uses one of these platforms, use that one.

## Commit attribution

Commits that RShift Sites pushes are not authored by the workspace member who triggered them. On GitHub they come from the RShift Sites GitHub app. On GitLab and Bitbucket, RShift Sites 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](/sites/integrations/github/#commit-attribution), [GitLab](/sites/integrations/gitlab/#commit-attribution), and [Bitbucket](/sites/integrations/bitbucket/#commit-attribution).

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**](https://lovable.dev/settings/git). 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 RShift Sites makes on a member's behalf carry that member's email address on its own line in the commit message body:

```text
Add a contact form

X-Lovable-Author-Email: member@example.com
```

Not every commit carries an address. Commits RShift Sites 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, RShift Sites 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.** RShift Sites cannot co-attribute their commits at all, so without this setting nothing in the repository records who triggered the change.
* **GitLab and Bitbucket repositories.** RShift Sites 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, RShift Sites stops adding addresses to new commits. A change already in progress finishes with the setting it started with.

> **Danger**
>
> **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. RShift Sites 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, RShift Sites 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 RShift Sites. Changes you make afterwards stay in RShift Sites only.

If you reconnect a project later, RShift Sites 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 RShift Sites. When you connect a project, RShift Sites always creates a new repository.
* **One repository per project.** Each RShift Sites project links to exactly one repository on one provider. To switch providers, [disconnect the project](#disconnecting-and-reconnecting) first.
* **One branch at a time.** Only commits on the synced branch appear in RShift Sites.
* **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. Each of these changes 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](/sites/features/drafts/) 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

**Do I need to know Git to use this?**

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.

**Do I need Git sync just to get a copy of my code?**

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](/sites/features/code-mode/). Git sync is for ongoing two-way sync and collaboration.

**Can I use more than one Git provider?**

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](#disconnecting-and-reconnecting) first.

**Does pushing to my repository update my live site?**

No. When you push commits, RShift Sites syncs your code and updates the preview in the editor, but it never publishes. Your live site only changes when you publish from RShift Sites. See [Publish your project](/sites/features/publish/).

**Is my database included in the repository?**

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 RShift Sites Cloud data](/sites/features/advanced-settings/#export-lovable-cloud-data).

**Can I import an existing repository into RShift Sites?**

No. Git sync only exports from RShift Sites. When you connect a project, RShift Sites creates a new repository.

**Do I need commit attribution if my team already connected their GitHub accounts?**

Usually not. On a GitHub repository, RShift Sites 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 RShift Sites does not add the co-author line.

**Can I remove member email addresses from commits I already pushed?**

Not from RShift Sites. When you disable **Include member email addresses in commits**, RShift Sites 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.

**Is my code still in RShift Sites after I connect?**

Yes. Your project remains fully editable in RShift Sites. The repository is a synced copy that you own. When you disconnect, RShift Sites deletes no code on either side.

## Related topics

- [Sync your RShift Sites project with GitLab](/sites/integrations/gitlab/)
- [Sync your RShift Sites project with GitHub](/sites/integrations/github/)
- [Workspace admin settings](/sites/features/workspace-admin-settings/)
- [RShift Sites for Enterprise](/sites/introduction/lovable-for-enterprise/)
- [Sync your RShift Sites project with Bitbucket](/sites/integrations/bitbucket/)

Source: https://help.rshift.com/sites/integrations/git-sync-overview/index.mdx