How to handle two Supabase environments in Flutterflow?

I have been building an app with a custom backend that I have deployed to AWS, but also using two separate Supabase environments named "Staging" and "Prod". I have a CI/CD setup in place for everything on the backend, and migrations are well handled for Supabase if I wish to make changes, test it in staging and later merge it into prod.

My main objective is speed of iteration, meaning that I am looking for the workflow with the least blockers to adding new features. My main concern is breaking changes to the schema, which are well handled on the backend, but I am afraid of how this is handled in my Flutterflow project.

My question is: What is the best approach to handle two environments when developing in Flutterflow?

I am aware of the following options which can split my work:

Environments: I am aware of Flutterflows development environments (https://docs.flutterflow.io/testing/dev-environments/). However, I am afraid of clicking the "Get schema" button when on my staging environment, since I suspect this will break a lot of things in my app that I will not be able to recover. How would I get back to the prod schema afterwards?
Branches: Would a branch be able to solve the above problem for me? Can I create a new branch, get the schema from staging, fix the breaking changes, and when satisfied merge this branch into my master? While doing this would I still be able to access the working prod app on the master branch?
Projects: I would like to avoid copying my project every time I want to add a new feature.

Finally, I would only like to make releases to app store when I am on the master branch with prod schema. I am worried that I would accidentally be able to build and deploy my app from the wrong environment - is there anything stopping that?