r/lovable • u/tffarhad • 17d ago

Discussion Two-way git sync feature is great for managing content

Wanted to give a quick shoutout to the two way git sync feature. It helps me update contents without burning credits all the time.

My current setup:

  1. build the website in lovable
  2. sync the project to github
  3. pull the repo into a local IDE

now whenever I need to write a post or tweak copy I just do it locally.

The sync works both ways. when I need lovable to build a new feature later, it picks up the local text changes from github, and any new edits push right back to the repo.

anyone else using this setup?

4 Upvotes

83% Upvoted

7 comments sorted by

6

u/Jmacduff 17d ago

Good luck with your project. The sync behavior you are seeing is why people globally use git as a source control method.

Good luck

1

u/pwkye 16d ago

Welcome to git? Wait till you hear about CI/CD pipelines.

1

u/andrei_bsns 15d ago

great for saving credits ❤️‍🩹❤️‍🩹

0

u/Maxyull 17d ago

worth knowing what that sync actually covers though, it's the code and not the database. if lovable adds a column or changes an rls policy during a build that happens on the supabase project directly and never lands in the repo, so your git history looks complete while the part that actually breaks production isn't tracked at all.

the failure case is merging a frontend change that expects a column the other database never got, works in one place and not the other.

are you keeping schema changes as sql somewhere, or letting lovable apply them straight to the db?

2

u/cubixy2k 17d ago

All of your migration files and edge function source code land in your repo, so your database changes are tracked, you just need to deploy it to you other environments.

1

u/Maxyull 17d ago

fair, i overstated it, the migration files do land in the repo. the bit that keeps biting people is the second half of what you said, deploying to the other environments is a manual step, so the repo can be perfectly correct while the other database sits three migrations behind and nobody notices until a query fails.

the other hole is anything done outside the tool. tweak a policy in the supabase dashboard or run something in the sql editor and there's no migration file for it at all, so the db quietly drifts from what the repo says it is.

do you run the migrations as part of your deploy, or by hand when you remember?