Git

Version control via GitHub requires FlutterFlow's Pro plan. If you're on Free or Standard, open your account settings and upgrade to Pro ($70/mo). Once on Pro, open your FlutterFlow project and navigate to the left-hand toolbar. Near the bottom, click the gear icon to open Settings, then choose Integrations from the settings menu. You will see a GitHub section. This is the only place you configure the Git connection — there is no terminal, no `git remote add`, no SSH key setup. Everything is handled through FlutterFlow's OAuth flow with GitHub. If your project is a team project, make sure the person setting this up has admin access to the target GitHub organization or repository, because the OAuth authorization needs permission to create and push to repos.

Click 'Connect GitHub' inside the integration panel. A GitHub OAuth popup opens in your browser — log in if you aren't already, then click 'Authorize FlutterFlow'. If your FlutterFlow project belongs to an organization, you'll also need to click 'Grant' next to that organization in the OAuth screen, otherwise the repo picker won't show org repos. After authorizing, return to FlutterFlow and use the repository dropdown to either pick an existing empty repo or create a new one. For a brand-new project, create a new repo with a meaningful name — something like `my-app-flutter` or `client-name-app`. Make sure the repo is initialized as empty (no README) so FlutterFlow's first push doesn't conflict with existing content. If you're connecting to an existing repo that already has commits, the first FlutterFlow push will overwrite the working tree — branch first before connecting if the repo has important hand-written code.

With the repo connected, you're ready to push your first commit. In the top-right area of the FlutterFlow editor you'll see a GitHub icon (sometimes labelled 'Push to GitHub' or showing the GitHub octocat logo). Click it. A dialog appears asking for a commit message — write something descriptive like 'Initial project scaffold with home screen and auth flow'. Then click 'Push'. FlutterFlow will package the entire generated Flutter project — `pubspec.yaml`, `lib/main.dart`, all screen Dart files, assets, platform folders — and commit it to the `main` branch of your connected repo. The push takes 10–30 seconds depending on project size. When it completes, open GitHub in a new tab and confirm you can see the commit in the repository. You should see a standard Flutter project structure: `lib/`, `android/`, `ios/`, `web/`, `pubspec.yaml`, `README.md`. This is now the same code a developer would open in VS Code or IntelliJ IDEA to run locally.

The best Git workflow for FlutterFlow is branch-per-feature: make changes in FlutterFlow, push to a dedicated branch, review the diff via a pull request (PR), and merge to `main` only when the feature is ready. To create a branch, open the branch selector in FlutterFlow's GitHub integration panel — it's usually a dropdown labeled with the current branch name (e.g. 'main'). Type a new branch name like `feature/profile-screen` and press Enter to create it. From now on, every push will go to that branch. Make your changes in FlutterFlow — add screens, adjust widgets, configure data types — then push with a descriptive commit message. On GitHub, you'll see the new branch appear with your commits. Open a pull request from `feature/profile-screen` → `main` to review the Dart diff before it lands in production. The diff shows every generated file that changed — which screens were added, which widget properties shifted, which navigation routes were updated.

Open the pull request on GitHub. You'll see a 'Files changed' tab that lists every Dart file FlutterFlow modified. Scan through it: did the new booking screen appear in `lib/pages/booking/booking_widget.dart`? Did the navigation route register correctly in `lib/app_state.dart`? This review step is where you catch accidental changes — sometimes editing one FlutterFlow screen touches shared components and the diff reveals unintended side effects. Once you're satisfied, click 'Merge pull request' on GitHub. The changes land on `main`. In FlutterFlow, switch the branch selector back to `main` to confirm the integration is pointing at the right branch for the next feature. You don't need to pull anything into FlutterFlow — the editor doesn't read from GitHub. GitHub is a downstream snapshot; FlutterFlow's database is always the live version of the app.

The most common source of pain with FlutterFlow + Git is misunderstanding which side owns the code. The rule is simple: FlutterFlow is the source of truth for all generated files. The GitHub repo is a read-mostly archive and CI trigger — never a place to hand-write Dart that you expect to survive. If a developer opens the repo, edits a widget Dart file locally, and commits that change to the branch, the next FlutterFlow push will silently overwrite their edit. Custom code that must survive exports belongs in FlutterFlow's own Custom Code panel (Custom Actions, Custom Functions, Custom Widgets) — FlutterFlow preserves those files even when regenerating other screens. Secrets — Firebase config, API keys, environment tokens — must never be committed to the repo; add `google-services.json`, `GoogleService-Info.plist`, and any key files to `.gitignore` immediately after the first push. For CI/CD pipelines that pick up the exported code (for example, a GitHub Actions workflow that runs `flutter test` and builds an APK), store secrets in GitHub Actions Secrets and inject them at build time, not in the Dart source.

1# .gitignore additions after FlutterFlow export
2google-services.json
3GoogleService-Info.plist
4*.keystore
5*.jks
6key.properties
7.env
8lib/firebase_options.dart   # if it contains real project IDs — regenerate in CI