How to develop safely after Lovable is connected to GitHub: branches, synchronization conflicts, rollback and deployment checks

“lovable vibe coding revenue” appears as a rising query on Google Trends in the United States.

What really determines whether a project can be maintained in the long term is not the speed at which the first version of the page is generated, but the way GitHub collaborates after it becomes a reliable source of truth.

Narrow the scope of the repository when installing GitHub App

Prefer Only select repositories.

Do not authorize individual accounts and all repositories of the entire organization.

Create a new warehouse for experimental projects to avoid connecting to existing production warehouses.

Review permissions in GitHub’s Applications settings after installation.

Record the installer, authorized organization, warehouse and date.

Save a clean baseline before connecting for the first time

1
2
3
4


git clone https://github.com/example/lovable-demo.git
cd lovable-demo
git status --short
git log -1 --oneline

Local copies are independent evidence for troubleshooting synchronization issues.

Observe the initial commit created by the Lovable immediately after connecting.

Check the author, file count, lock file and environment variable examples.

Real .env should not go into commit.

First determine who can change the default branch

Enable protection for the default branch.

Requires a Pull Request, status check, and at least one review.

Don’t allow force push just to make the build process easier.

Modifications to Lovable are entered into the feature branch and then merged through PR.

Local developers follow the same rule.

The root cause of synchronization conflicts is usually simultaneous editing in both directions

When Lovable and the local IDE modify the same component at the same time, conflicts are inevitable.

Before starting a Lovable session, synchronize the latest remote submission.

The associated file is considered occupied during the session.

Submit it immediately after completion and notify other developers.

Don’t accumulate dozens of builds into one big commit that can’t be reviewed.

Conflict handling is subject to code semantics

1
2
3


git fetch origin
git diff origin/main...HEAD
git diff --check

If there is a lock file conflict, do not manually splice the text on both sides.

Rerun the package manager build after selecting the correct dependency declaration.

If the component conflicts, the page must be run locally, and the Agent cannot just choose “Keep Both Sides”.

Environment variables only submit the name and description

.env.example can contain:

1
2
3


VITE_API_URL=https://api.example.test
SUPABASE_URL=https://project.supabase.co
SUPABASE_ANON_KEY=replace-me

Do not put service role key, database password or payment platform key.

Even if the browser-side variable is called secret, it may still be entered into the front-end package.

Search build products before going online:

1

rg -n "service_role|sk_live_|BEGIN PRIVATE KEY" dist

Only four types of high-risk changes will be reviewed after each generation

Let’s look at authentication and permissions first.

Let’s look at database migration again.

Then look at external APIs and payments.

Finally, look at delete and overwrite operations.

Style adjustments can be reviewed quickly, but safety boundaries cannot be sampled by file count.

Establish minimum CI threshold

1
2
3
4
5


npm ci
npm run lint
npm run typecheck
npm test
npm run build

The command is subject to the actual script of the project.

When the build tool removes tests, CI should show the change in the number of tests.

A successful build does not mean that the login and payment processes are correct.

Add at least one end-to-end smoke test.

Release using trackable version

Each production release corresponds to a Git commit.

Record the commit SHA on the deployment platform.

1
2
3


git rev-parse HEAD
git tag deploy-2026-07-27-01
git push origin deploy-2026-07-27-01

Tags are just anchor points and do not replace branch protection.

Rollback is not “let the AI change back”

First, switch back to the previous successful build on the deployment platform.

Then use Git revert to generate clear reverse commits.

1

git revert <bad-commit>

Front-end rollback may not be enough when the database has been migrated.

Migration must prepare forward fix or compatibility paths in advance.

Don’t assume that destructive migration can be automatically reversed.

Ending when disconnecting integration

Confirm that all Lovable modifications have been pushed.

Export necessary project descriptions.

Revoke the App’s warehouse permissions on GitHub.

Rotate third-party keys once exposed to the project.

Verify that CI and deployment no longer rely on Lovable’s temporary identities.

Pre-launch checklist

GitHub App only accesses specified repositories.
The default branch prohibits direct push.
Each build corresponds to a small reviewable commit.
.env and production keys are not in Git.
CI includes lint, types, tests and builds.
Authentication, payment and data permissions are manually verified.
Deployments can be mapped to commit SHA.
Frontend and database rollbacks rehearsed.

When GitHub saves auditable history, Lovable transforms from a one-time prototyping tool into a manageable development entry point.

GitHub integration documentation

Check out what GitHub App can actually do

Open the Lovable installation details on the GitHub Apps page of the organization settings and record the Repository permissions and Organization permissions respectively. Focus on Contents, Pull requests, Actions, Secrets and Administration.

If your current workflow only requires synchronizing code, you shouldn’t grant org management permissions to save trouble. Privilege escalations must have a new business justification and be confirmed by the warehouse administrator.

Authorized warehouses are inspected quarterly. Archived projects, temporary demo warehouses, and customer warehouses that have been handed over should be removed in a timely manner.

Protect sensitive directories with CODEOWNERS

Specify the person in charge who must participate in the review in .github/CODEOWNERS:

1
2
3
4


/supabase/migrations/  @example/database-team
/.github/workflows/    @example/platform-team
/src/auth/             @example/security-team
/src/payments/         @example/payments-team

Then enable Code Owner approval in branch protection rules. GitHub will not force a wait for approval from the responsible person when only the file exists and the rule is not enabled.

The generation tool can still quickly merge when modifying ordinary pages; when it comes to certification, migration and deployment configuration, it will automatically enter a more stringent review path.

Limit a Lovable session to one PR

Create a branch with a task number before the session starts:

1

git switch -c lovable/issue-142-profile-form

Only allowing this round of builds resolves issue 142. When other problems are found, write them into new issues and fix them if they are not in the same branch.

Commit information describing user-visible changes and validation commands. A screenshot is attached to the PR description, but the screenshot must hide email, access token, and customer data.

Compare file list before and after synchronization

1
2


git diff --name-status origin/main...HEAD
git diff --numstat origin/main...HEAD

If you modify a button but have routing, authentication, or dozens of dependencies change, pause synchronization first. Check if re-scaffolding, a global rewrite of the lock file, or incorrect base branch selection has occurred.

Big changes are not necessarily malicious, but should not be mixed with a small UI PR.

GitHub Actions Use least privileges

Explicitly declare permissions at the beginning of the workflow:

1
2


permissions:
  contents: read

Add checks: write only if you need to publish the check results. PR builds do not require contents: write, nor do they require access to all environment secrets.

PRs from forks do not execute workflows with production credentials. Third-party actions are pinned to the commit SHA and updated via Dependabot or a manual process.

The Preview environment is separated from the production environment

Each PR can create a Preview URL, but it can only connect to the test database and test payment account. Obvious non-production marks are displayed on the page to prevent business personnel from mistakenly recording real data.

The Preview is automatically destroyed after it expires. The destruction action does not delete other branch data in the shared test database, but cleans up its own tenant or schema by branch ID.

Merge order of database migration

Apply the migration in the Preview database first, run compatibility tests, and then merge the application code. Production deployments employ forward-compatible two-phase changes.

For example, when adding a new field, first allow the old code to ignore it; wait until the new code is stable before adding stricter constraints. To delete a field, stop reading first and observe a release cycle before migrating.

Use GitHub audit logs to track abnormal synchronization

Organization accounts can query app installations, permission changes, and warehouse access from audit logs. When an unknown submission occurs or a large number of warehouses are authorized, pause the app first, and then save the log evidence.

Do not delete the abnormal branch immediately. Save commit, author, time, and GitHub delivery ID to help differentiate between user actions, automated syncs, and credential abuse.

Real rollback drill

Choose a Preview build and deploy a commit that intentionally has visual errors but does not destroy data. Record the current SHA and switch back to the previous version.

Confirm that the CDN cache, front-end resources, and API versions are all restored. Verify again after forcing the browser to refresh to avoid mistaking the local cache for a successful rollback.

Then execute git revert so that the default branch history also reflects this rollback. Deployment platform rollback and source code rollback are indispensable.

Checklist when handing over the project

After the project is handed over to other teams, the ownership of the warehouse administrator, deployment platform, domain name, Supabase and payment account is transferred. Lovable App reauthorizes to the repository managed by the recipient.

Rotate build and deployment keys, close old team member sessions. Finally, a clone, build, and deployment are completed from a new account, proving that the project does not rely on the original developer’s computer.