I’m Not a Git Expert — Here’s How I Figured Out a Workflow with Lovable, Netlify, and GitHub
I want to start by clarifying something so this is read from the right place: I’m not a Git expert. Everything I share here comes from my recent learning experience.
I don’t come from large engineering teams or years of designing perfect workflows. I come from building a product, launching it quickly, making mistakes, fixing things on the fly, and learning while the product was already being used.
Along the way, I started using in a more structured way, with branches, environments, and automatic deployments on Netlify. At the same time, Lovable was the tool I was using to build almost everything. There wasn’t a clear guide on how to use both together, so I had to experiment, break things, fix them, and adjust until the workflow started to feel natural.
I’m not writing this as a universal recipe. I’m writing it because once I found a way of working that gave me structure without slowing me down, I felt it was worth sharing.
The problem wasn’t Git or Lovable
For quite a while, I found myself stuck on very basic questions:
- Should I make this change here or in another branch?
- How do I test this feature with real users?
- Should I fix this bug where I found it, or where it should have been fixed?
- How do I avoid fixing the same thing multiple times?
It wasn’t that GitHub was complicated or that Lovable had strange limitations. The real issue was that I didn’t have a clear mental model of how environments and branches connected. On top of that, one of the biggest challenges was managing Supabase test databases without risking anything in production.
When that isn’t clear, any tool becomes confusing.
Three clearly defined environments
The first thing that really helped was being very explicit about the environments I had and what each one was for.
In the end, I settled on three, each one with its own separate database:
- Production, which is what real users interact with
- Staging, where changes are tested before going live
- Dev, where day-to-day work is integrated
I always assigned the same branch to each environment:
- `main` → Production
- `staging` → Testing and releases
- `dev` → Development
And each one had its own Supabase or Lovable Cloud database, taking advantage of the two free Supabase test projects and the default environment provided by Lovable Cloud:
- Supabase Prod → Production
- Supabase Stg → Testing and releases
- Lovable Cloud → Development
This might sound obvious, but having this fixed removed a lot of uncertainty. Whenever something failed, I at least knew where to start looking.
The logical approach would be to use Supabase branching, but that’s only available on paid plans. Since this project is bootstrapped, I try to keep costs low. Yes, it’s more complex, but for me, it’s worth it.
How I started using Lovable and GitHub together
Lovable doesn’t do Git for you, and that’s fine. What it did give me was something crucial: clarity of context.
I stopped thinking so much in terms of commands and started thinking in simpler questions:
- Am I working in development?
- Am I fixing something that already exists?
- Is this in production?
Being able to switch branches from Lovable, knowing that each branch represented a different environment, made me much more aware of what I was doing. GitHub was still the source of truth, but Lovable became the place where I made decisions with less friction.
It wasn’t that someone told me “this is the correct workflow.”
It was more about finding a way to use both tools together that actually made sense to me.
A simple rule that helped a lot
Over time, I noticed a pattern that worked for me and summarized it in a very simple idea:
Features move up.
Fixes move down.
In practice, that meant:
- New functionality starts in `dev` and moves toward production.
- Bugs found in production are fixed in `main` and then propagated to `staging` and `dev`.
It’s not a sophisticated rule, but it helped me stay oriented and avoid fixing the same issue multiple times in different places.
How I work today with new features
For new work (for example, what became MVP 2.0), I follow a fairly simple approach:
- Everything starts from `dev`
- Each feature gets its own branch
- I work on one feature, finish it, merge it back into `dev`, and move on to the next one
I don’t wait for the entire sprint to be finished before integrating. I prefer integrating frequently and keeping `dev` reasonably stable, even if it’s not perfect.
When `dev` starts to make sense as a whole, that’s when it moves to `staging` and the more formal testing cycle begins.
And when something fails in production
That happens. And it will keep happening.
When I find an issue in production:
- I create a hotfix directly from `main`
- I fix only what’s necessary
- I publish a new version
- And then I propagate that change down to `staging` and `dev`
That way, I don’t lose track of what happened and I don’t leave branches out of sync.
In summary: the workflow I use and that works for me
All of the app development happens in Lovable, which I treat like an IDE. I connect the project to GitHub and Netlify, and from Lovable I create the branches I need (in my case, two main ones).
My current way of working is fairly straightforward: everything new starts in `dev`. From there, I create a branch for each feature and work on it until the functionality stands on its own.
Once it’s ready, I merge it back into `dev` and move on to the next feature, without waiting to close the entire sprint.
When the set of changes in `dev` feels stable enough, I move it to `staging` to test more calmly, fix bugs, and prepare releases.
If something fails in production, I don’t improvise. I create a hotfix directly from `main`, publish a new version, and then propagate that change to `staging` and `dev` so it doesn’t get lost.
It’s not a perfect workflow, but over time, it’s allowed me to move faster, make fewer mistakes, and always know where I’m standing without affecting users in the production environment.
This is a very rough representation of that flow:
More than tools, it’s a way of thinking
I don’t think this works just because I use Lovable, GitHub, or Netlify.
I think it works because I forced myself to think more carefully about how I wanted to work, not just which tools I was using.
Lovable helped me move between contexts with less friction.
GitHub gave me history and control.
Netlify gave me visibility into what was deployed in each environment.
But the workflow, with all its mistakes and adjustments, is something I built myself.
Final thoughts
I still don’t consider myself a Git expert, and I don’t know if this is the most efficient approach. But today, I work with much more peace of mind.
If you’re building a product and constantly second-guessing where each change should go, maybe you don’t need more commands or more tools, but rather a workflow that actually makes sense to you.
Hopefully, this experience can serve as a starting point for finding your own.
