You spent three weeks building an app in your favorite AI coding tool. It worked. You then started working on a new feature. You built it, made changes, saved… and discovered your new feature is broken and the original app is ruined too.
This isn't a bug with your AI coding tool. This is what happens when you ship AI-generated code without version control. The good news? You can protect yourself in 15 minutes.
This guide shows you the exact Git workflow that prevents lost work and enables fast iteration—no matter which AI builder you use.
Why Git Matters When AI Writes Your Code
You're racing to revenue, not learning Git workflows. But here's the truth: losing work is slower than learning the basics.
When AI generates 90% of your code, Git becomes your production ledger. Every commit is a restore point. Every branch is a safe experiment space.
One developer put it perfectly after exporting from Lovable without Git:
"I have no version history, no way to test things separately. It's a house of cards and I'm scared to touch anything."
Think of Git as your undo button for entire features. When an AI prompt goes wrong (and it will), you rewind in seconds instead of rebuilding for hours.
First step: The second you export from Lovable, Base44, or Bolt, open your terminal (Terminal on Mac, Command Prompt or PowerShell on Windows) and navigate to your project folder. Then run:
```bash label="Terminal"
git init
git add .
git commit -m "Initial export from [platform]"
Then create a private GitHub repo and push:
```bash label="Terminal"
gh repo create my-app --private
git remote add origin https://github.com/you/my-app.git
git push -u origin main
Takes 2 minutes. Saves days of recovery work later.
You can also prompt Cursor or Claude to create a GitHub repo for you:
```prompt label="Cursor / Claude Code"
Initialize the repo
set remote to https://github.com/you/my-app.git
do an initial commit and push
## The Three Mistakes That Erase Hours of Work
These happen in week one, before you realize you need the ability to rollback safely.
### Mistake 1: Working Directly on Main
You've exported code from your AI coding tool and started working on a new feature. Something breaks. Now you're debugging instead of shipping. This is what happens when you ship AI-generated code without version control.
**The fix**: Never work on `main`. Use feature branches for every change.
```bash label="Terminal"
## Before every AI coding session
git checkout -b feature/add-user-login
## Make changes, test locally
git add .
git commit -m "User login working"
You can also prompt Cursor or Claude to create a feature branch for you:
```prompt label="Cursor / Claude Code"
Create a feature branch for the user login feature
Then, if it works, merge it to main:
```bash label="Terminal"
## If it works, merge it
git checkout main
git merge feature/add-user-login
You can also prompt Cursor or Claude to merge the feature branch to main for you:
```prompt label="Cursor / Claude Code"
Merge the feature branch for the user login feature to main
If AI broke it, delete the branch and start over:
```bash label="Terminal"
## If AI broke it, delete the branch and start over
git checkout main
git branch -D feature/add-user-login
You can also prompt Cursor or Claude to delete the feature branch for you:
```prompt label="Cursor / Claude Code"
Delete the feature branch for the user login feature
Your production code stays safe. AI experiments stay isolated.
### Mistake 2: Keeping Secrets Only in Your AI Coding Tool's Environment Settings
You store API keys in your AI coding tool's environment settings. If you want to move off the tool like Lovable, Replit, or Base44 to manage your own code with GitHub and run it locally, you're stuck. Nothing works.
**The fix**: Keep a `.env.example` file in Git (without actual secrets):
```bash
## .env.example - commit this
STRIPE_PUBLIC_KEY=pk_test_...
OPENAI_API_KEY=sk-...
DATABASE_URL=postgresql://...
The .env.example is helpful to document what secrets are needed to run your app.
Fix 2: Keep a .env file with the actual secrets so your app runs locally. Add it to your .gitignore file so it's not committed to Git.
```bash Terminal
.env - NEVER commit this (add to .gitignore)
STRIPE_PUBLIC_KEY=pk_test_abc123real
OPENAI_API_KEY=sk-xyz789real
DATABASE_URL=postgresql://user:pass@localhost/db
Now you have a template. When disaster strikes, you know exactly which secrets to re-create.
#### What is the `.env` file?
The `.env` file is a file that contains environment variables for your app. It's a way to store sensitive data like API keys and secrets so they're not committed to Git.
#### What is the difference between a `.env.local` and a `.env` file?
For a detailed explanation on the differences and best practices, refer to our dedicated post: [Understanding .env and .env.local Files](https://www.braingrid.ai/blog/env-local-vs-env).
#### What is the .gitignore file?
The `.gitignore` file is a list of files and directories that Git should ignore. It's a way to prevent sensitive data from being committed to Git.
### Mistake 3: Downloading Projects Without Git
Some people download their Lovable, Replit, or Base44 projects from the UI. Then edit the code directly.
**The fix**: Always connect to GitHub, then clone the repo locally.
```bash label="Terminal"
## Clone your project
git clone https://github.com/you/project.git project-copy
BrainGrid's GitHub integration tracks requirements across branches—so can keep track what each branch is doing.
The Ideal Git Workflow for AI Builders
Here's the branching strategy that keeps your code safe while moving fast.
Branch Structure
gitGraph
commit id: "Initial commit"
branch dev
checkout dev
commit id: "Setup dev"
branch feature/login
checkout feature/login
commit id: "Add login UI"
commit id: "Connect auth"
checkout dev
merge feature/login
branch feature/dashboard
checkout feature/dashboard
commit id: "Dashboard layout"
checkout dev
merge feature/dashboard
checkout main
merge dev tag: "v1.0.0"
Two main branches:
-
main- Production code that's live or ready to ship -
dev- Integration branch for features being built
Feature branches: One per feature, created from dev
Daily Workflow
Morning: Start fresh from dev
```bash label="Terminal"
git checkout dev
git pull origin dev
git checkout -b feature/user-profile
**During work**: Commit every time something works
```bash label="Terminal"
## Test your change, it works!
git add .
git commit -m "User profile page displaying correctly"
End of day: Push your feature branch
```bash label="Terminal"
git push origin feature/user-profile
**When feature is done**: Create PR to dev
```bash label="Cursor / Claude Code"
Create a Pull Request from the feature/user-profile
branch to the dev branch
When dev has multiple features ready: Merge to main
## On GitHub, create Pull Request: dev → main
## Review all changes, merge PR
## Tag the release
git checkout main
git pull origin main
git tag -a v1.0.0 -m "First production release"
git push origin v1.0.0
Claude Code / Cursor prompt:
```prompt label="Cursor / Claude Code"
Create a Pull Request from the dev branch to the main branch
### Pull Request Process
```mermaid
graph LR
A[Feature Branch] -->|Pull Request| B[dev branch]
B -->|Accumulate features| B
B -->|Pull Request when ready| C[main branch]
C -->|Tag and Push to GitHub| D[v1.0.0]
Feature → dev Pull Request: Review individual changes, merge quickly
dev → main Pull Request: Review entire release, test thoroughly, then merge and tag
This gives you:
- Safe experiments on feature branches
- Integration testing on dev
- Clean, tagged production releases on main
Branch Naming Best Practices
Use descriptive names that explain what you're building:
```bash label="Terminal"
✅ Good
feature/stripe-checkout
feature/email-notifications
fix/dashboard-loading
hotfix/payment-webhook
❌ Bad
feature/new-stuff
fix/bug
my-branch
Pattern: `type/short-description`
**Types**:
- `feature/` - New functionality
- `fix/` - Bug fixes
- `hotfix/` - Urgent production fixes
- `refactor/` - Code cleanup without behavior change
## Daily Habits That Prevent Disasters
These take 30 seconds but save hours of recovery work.
### Morning Routine
```bash label="Terminal"
## Sync latest changes
git checkout dev
git pull origin dev
## Create today's feature branch
git checkout -b feature/todays-work
After Every Working Feature
```bash label="Terminal"
It works! Lock it in.
git add .
git commit -m "Feature X working: [brief description]"
Don't wait until the feature is "perfect." Commit when it works, even if it's ugly.
### Before AI Prompts That Regenerate Code
```bash label="Terminal"
## Safety commit before letting AI regenerate
git add .
git commit -m "Before AI regeneration - working state"
Now if the AI breaks everything, you're one command away from safety:
```bash label="Terminal"
git reset --hard HEAD
### End of Day
```bash label="Terminal"
## Cloud backup - never lose work
git push origin feature/todays-work
Even if your laptop dies, your work is safe on GitHub.
The payoff: With these habits, you can ship several features per week to beta users instead of getting stuck trying to fix one feature that's broken, accelerating the feedback loops that inform your product roadmap.
BrainGrid's task system reminds you to commit after completing each task—turning version control into a built-in habit instead of something you remember after disaster strikes.
When Disaster Strikes: Recovery Playbook
Even with perfect habits, AI builders sometimes create chaos.
Scenario 1: AI Broke Everything (But You Committed)
Find your last working commit:
```bash label="Terminal"
git log --oneline
Shows: abc1234 Feature X working
def5678 Before AI regeneration
ghi9012 Login flow complete
git reset --hard def5678
You're back to the working state. The AI's chaos is gone.
**Important**: Only use `--force` when pushing to feature branches, never to main:
```bash label="Terminal"
git push origin feature/broken-thing --force
Scenario 2: Accidentally Committed Secrets
Undo the last commit, keep your changes:
```bash label="Terminal"
git reset --soft HEAD~1
Remove secrets from files, add to .gitignore
echo "API_KEY=sk-real-secret" >> .env
echo ".env" >> .gitignore
Commit again without secrets
git add .
git commit -m "Fixed: removed secrets from commit"
### Scenario 3: Total Catastrophe (No Recent Commits)
Use the AI builder's version history:
**Base44**: Click clock icon → restore last working version → export immediately → commit
**Lovable**: Check GitHub commits (if auto-sync enabled) → revert to working commit
**No Git, no builder history**: You're rebuilding from memory. Don't let this be you.
### The Nuclear Option
If everything is broken and Git history is tangled:
```bash label="Terminal"
## Clone a fresh copy from last known good point
git clone https://github.com/you/project.git project-recovery
cd project-recovery
git checkout <commit-hash-that-worked>
## Copy your .env file back
cp ../old-project/.env .
## Start fresh branch from here
git checkout -b feature/rebuild
Recovery speed matters: 10 minutes of downtime vs. 10 hours determines whether you keep customer trust and revenue momentum.
Quick Reference: Essential Git Commands
Setup & Daily Use
```bash label="Terminal"
Start new feature
git checkout dev
git pull origin dev
git checkout -b feature/my-feature
Save progress
git add .
git commit -m "Description of what works"
git push origin feature/my-feature
Merge feature to dev (via PR on GitHub)
Then locally:
git checkout dev
git pull origin dev
### When Things Break
```bash label="Terminal"
## See what changed
git status
git diff
## Undo changes (not committed yet)
git checkout -- filename.ts
## Undo last commit (keep changes)
git reset --soft HEAD~1
## Undo last commit (discard changes)
git reset --hard HEAD~1
## Go back to any commit
git log --oneline
git reset --hard <commit-hash>
Branch Management
```bash label="Terminal"
List branches
git branch -a
Delete local branch
git branch -D feature/old-thing
Delete remote branch
git push origin --delete feature/old-thing
Rename current branch
git branch -m new-name
## Start Protecting Your Work Today
Here's your 15-minute setup:
1. **Initialize Git** in your exported project
2. **Create GitHub repo** and push
3. **Create `dev` branch** from `main`
4. **Make a `.gitignore`** file (add `.env`, `node_modules`, `.next`)
5. **Commit daily** - make it a habit
The first time you need to rollback a broken AI generation, you'll be glad you did.
Version control isn't about "adding complexity." It's about protecting the hours you invested and shipping faster to paying customers.
---
*Originally published on the [BrainGrid blog](https://www.braingrid.ai/blog/git-version-control-for-ai-builders).*
Top comments (0)